Messages in this thread | | | Date | Mon, 6 Sep 2004 15:35:23 +0200 | From | Jörn Engel <> | Subject | Re: [PATCH 1/3] copyfile: generic_sendpage |
| |
On Mon, 6 September 2004 14:45:38 +0200, Gunnar Ritter wrote: > > It is an even more serious problem in my experience. I have been > using sendfile() in my cp command at <http://heirloom.sourceforge.net> > for quite some time, and I quickly decided to send files separated in > some decently sized blocks. Otherwise if a whole file is sent at once > and the source file is e.g. on an uncached floppy disk, cp will become > uninterruptible for about a minute, which is a serious usability flaw. > The user might discover that he is copying the wrong file, or he might > simply change his mind and like to abort the copy or whatever. A > performance gain of only 10 % is neglegible in comparison to this > problem. Thus I think if copyfile() would not be interruptible by SIGINT > and friends, its practical value would be quite limited.
Using a loop of 4k sendfile commands should be easy enough to do. Problem is that copyfile(2) should do some decent cleanup after receiving a signal. Hans Reiser got it right that all filesystem operations should be atomic.
Jörn
-- Premature optimization is the root of all evil. -- Donald Knuth - 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/
| |