Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 27 Nov 2003 19:56:35 +1100 | From | Nick Piggin <> | Subject | Re: OT: why no file copy() libc/syscall ?? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |