Messages in this thread | | | Date | Thu, 13 Nov 2003 16:04:16 -0800 | From | jw schultz <> | Subject | Re: OT: why no file copy() libc/syscall ?? |
| |
On Fri, Nov 14, 2003 at 12:39:15AM +0100, Andrea Arcangeli wrote: > On Thu, Nov 13, 2003 at 12:22:14PM -0800, H. Peter Anvin wrote: > > Followup to: <20031111085323.M8854@devserv.devel.redhat.com> > > By author: Jakub Jelinek <jakub@redhat.com> > > In newsgroup: linux.dev.kernel > > > > > > > > Actually, I think we should have a: > > > > > > > > long copy_fd_to_fd (int src, int dst, int len) > > > > > > > > type of systemcall. > > > > > > We have one, sendfile(2). > > > > > > > It would be very nice if we could (a) expand the uses of sendfile(2), > > and (b) have the libc do the fallback to read/write/mmap as needed. > > I actually hacked cp for a while and it improved cp some point percent > on normal machines. > > See ftp://ftp.suse.com/pub/people/andrea/cp-sendfile/ > > the main downside and the reason it wasn't applied IIRC is the lack of > interruption of sendfile, basically for an huge file it would take a > while before C^c has any effect. The kernel isn't interrupting the > syscall. This is no different from a huge read or write syscall (but > read/write are never huge or the buffer would need to be huge too, not > the case for sendfile that works zerocopy), so in theory we could > workaround it by entering/exiting kernel multiple times just to allow > the signal to be handled like in the read/write case.
Until interrupt and restart (as has been discussed here for other syscalls) handling is improved there could be a sanity check with an E2BIG or something if the size is insane. I dislike the thought of sendfile going sitting in D state on a multi-gigabyte file.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws
Remember Cernan and Schmitt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |