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@xxxxxxxxxx Phone: (650) 506-8127 -- 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
