On Tue, 5 May 2009 16:36:29 +0100, Jamie Lokier wrote: > > I'm wondering why reflink() is needed at all. Can't it be done in > userspace, using the BTRFS ioctl? The hard part in userspace seems to > be copying the file attributes, but "cp -a" and other tools manage. > > What is the advantage of adding the system call for the special case > of reflink(), when we choose not to have, say, a copyfile() system > call which does what "cp -a" does because doing it in user space is > good enough? Given an ignorant filesystem, copyfile() will simply do the read/write loop in kernelspace. So either copyfile() is just a fancy name for splice() or copyfile() will also have to create a tempfile, rename the tempfile when the copy is done and deal with all possible errors. And if the system crashes, who will remove the tempfile on reboot? Will the tempfile have a well-known name, allowing for easy DoS? Or will it be random, causing much fun locating it after reboot. In short, copyfile() for ignorant filesystems is steaming load of it. I know, I've written it [1]. When implemented in the filesystem itself, copyfile() can be quite nice. The filesystem can create a temporary inode without visibly exposing it to userspace. It can delete temporary inodes in journal replay after a crash. And depending on the fs design, the read/write loop can be replaced with finer-grained reference counting. [1] Not a year or two ago, but in 2004, btw. Jörn -- Do not stop an army on its way home. -- Sun Tzu -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
