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

[Joel Becker]

On Tue, May 05, 2009 at 11:30:16PM +0100, Jamie Lokier wrote:
> Joel Becker wrote:
> > 	I think I'm confusing you.  ocfs2 creates a new inode, with a
> > new tree of extent blocks, pointing to the same data extents as the
> > source.  You can do *anything* POSIX to that new inode.  You can chown
> > it, chmod it, truncate it, futimes it, whatever.  The only thing at
> > issue is what the state of the inode is at the return of the reflink()
> > call.
> 
> Ok, but does chown/chmod/futimes trigger a COW copy, unsharing the data?
> This is still not clear. :-)

	No, of course it doesn't.  That would be awful!

> But assuming it stays shared until you modify the actual data, could
> the documentation make this important fact a bit more prominent:
> 
>     reflink() creates a new file which initially shares the same
>     underlying data storage as the source file, and has all the same
>     attributes including security context and extended attributes.
> 
>     After creating the new file, you can do *anything* POSIX to that
>     new file.  You can chown it, chmod it, futimes it, truncate it,
>     write to it, whatever.  When the data is modified, that will
>     trigger a copy-on-write operation so that the underlying data is
>     not completely shared any more.
> 
>     The amount and timing of copying is filesystem-dependent, but only
>     happens when a data write or extended attribute change takes place.
> 
>     Opening a file, reading it, read-only or private mappings, and
>     simple attribute updates (chown, chmod, futimes, as well as
>     automatic atime updates) will not trigger copy-on-write and will
>     not return ENOSPC errors.

	You got it.

Joel

-- 

"In the room the women come and go
 Talking of Michaelangelo."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127