From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: [PATCH 1/3] fs: Document the reflink(2) system call. Date: Tue, 5 May 2009 15:37:30 -0700 Message-ID: <20090505223730.GR7835@mail.oracle.com> References: <1241331303-23753-1-git-send-email-joel.becker@oracle.com> <1241331303-23753-2-git-send-email-joel.becker@oracle.com> <20090505010703.GA12731@shareable.org> <20090505071608.GB10258@mail.oracle.com> <20090505130114.GD17486@mit.edu> <20090505170058.GD7835@mail.oracle.com> <20090505223016.GF7574@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Theodore Tso , jmorris@namei.org, ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk To: Jamie Lokier Return-path: Content-Disposition: inline In-Reply-To: <20090505223016.GF7574@shareable.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com List-Id: linux-fsdevel.vger.kernel.org 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@oracle.com Phone: (650) 506-8127 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Date: Tue, 5 May 2009 15:37:30 -0700 Subject: [Ocfs2-devel] [PATCH 1/3] fs: Document the reflink(2) system call. In-Reply-To: <20090505223016.GF7574@shareable.org> References: <1241331303-23753-1-git-send-email-joel.becker@oracle.com> <1241331303-23753-2-git-send-email-joel.becker@oracle.com> <20090505010703.GA12731@shareable.org> <20090505071608.GB10258@mail.oracle.com> <20090505130114.GD17486@mit.edu> <20090505170058.GD7835@mail.oracle.com> <20090505223016.GF7574@shareable.org> Message-ID: <20090505223730.GR7835@mail.oracle.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jamie Lokier Cc: linux-fsdevel@vger.kernel.org, Theodore Tso , jmorris@namei.org, ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk 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