[Ocfs2-devel] [PATCH 1/3] fs: Document the reflink(2) system call.

["Jörn Engel" <joern@logfs.org>]

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