Re: OT: why no file copy() libc/syscall ??

[Nick Piggin]

David Lang wrote:

> On Thu, 27 Nov 2003, Nick Piggin wrote:
>
>
> > Robert White wrote:
> >
> >
> > > (Among the other N objections, add things like the lack of any sort of
> > > control or option parameters)
> > > ...
> > > N += 1: Sparse Copying (e.g. seeking past blocks of zeros)
> > > N += 1: Unlink or overwrite or what?
> > > N += 1: In-Kernel locking and resolution for pages that are mandatory
> > > lock(ed)
> > > N += 1: No fine-grained control for concurrency issues (multiple writers)
> > >
> > > Start with doing a cp --help and move on from there for an unbounded list of
> > > issues that sys_copy(int fd1, int fd2) does not even come close to
> > > addressing.
> > To be fair, sys_copy is never intended to replace cp or try to be
> > very smart. I don't think it is semantically supposed to do much more
> > than replace a read, write loop (of course, the syscall also has an
> > offset and count).
> >
> > sparse copying would be implementation dependant. If cp wanted to do
> > something special it would not use one big copy call. I think unlink
> > / overwrite is irrelevant if its semantically a read write loop.
>
> actually if this syscall is allowed to do a COW at the filesystem level
> (which I think is one of the better reasons for implementing this) then
> sparse files would produce sparse copies.

Sure, I just mean the semantics should be equivalent to a read write
loop. Another example is zero copy copy for a remote fs that supports
it.

> if the destination exists it would need to be unlinked (overwrite doesn't
> make sense in the COW context)

Well it would be implementation specific. Presumably it should keep
the semantics of an overwrite.

> I don't understand the in-kernel page locking issues refered to above
>
> the concurrancy issues are a good question, but I would suggest that the
> syscall fully setup the copy and then create the link to it. this would
> make the final creation an atomic operation (or as close to it as a
> particular filesystem allows) and if you have multiple writers doing a
> copy to the same destination then the last one wins, the earlier copies
> get unlinked and deleted

I don't think it should do any linking / unlinking it should just work
with file descriptors. Concurrent writes to a file don't have many
guarantees. sys_copy shouldn't have to be any stronger (read weaker).

> I definantly don't see it being worth it to make a syscall to just
> implement the read/write loop, but a copy syscall designed from the outset
> to do a COW copy that falls back to a read/write loop for filesystems that
> don't do COW has some real benifits

No I just mean the semantics.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/