Matthew Ahrens wrote:
Will Murnane wrote:
On 6/23/07, Erik Trimble <[EMAIL PROTECTED]> wrote:
Now, wouldn't it be nice to have syscalls which would implement "cp"
and
"mv", thus abstracting it away from the userland app?
>
Not really. Different apps want different behavior in their copying,
so you'd have to expose a whole lot of things - how much of the copy
has completed? how fast is it going? - even if they never get used by
the userspace app. And it duplicates functionality - you can do
everything necessary in userspace with stat(), read(), write() and
friends.
A "copyfile" primitive would be great! It would solve the problem of
having all those "friends" to deal with -- stat(), extended
attributes, UFS ACLs, NFSv4 ACLs, CIFS attributes, etc. That isn't to
say that it would have to be implemented in the kernel; it could
easily be a library function.
--matt
I'm with Matt. Having a "copyfile" library/sys call would be of
significant advantage. In this case, we can't currently take advantage
of the CoW ability of ZFS when doing 'cp A B' (as has been pointed out
to me). 'cp' simply opens file A with read(), opens a new file B with
write(), and then shuffles the data between the two. Now, if we had a
copyfile(A,B) primitive, then the 'cp' binary would simply call this
function, and, depending on the underlying FS, it would get implemented
differently. In UFS, it would work as it does now. For ZFS, it would
work like a snapshot, where file A and B share data blocks (at least
until someone starts to update either A or B).
There are other instances of the various POSIX calls which make it hard
to take advantage of modern advanced filesystems, while still retaining
backwards compatibility.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
