![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 13:58 [from the cache] ©2003-2008 | |||||||||||||