Re: [PATCH 1/3] copyfile: generic_sendpage

[Gunnar Ritter <Gunnar.Ritter@pluto.uni-freiburg.de>]

Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:

> 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.

Heck, guess what I did (although 4k seems a bit small).

> 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.

Then I don't see the point in having a copyfile system call. In
fact, I would consider to deactivate it in every kernel derivative
I'm responsible for to prevent hanging applications.

	Gunnar