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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 05, 2009 at 10:57:11PM +0100, Jamie Lokier wrote:
> jim owens wrote:
> > 3) the granularity of the COW (1-byte write may cause
> >    1-block up through whole file copy) is fs-dependent.
> 
> And yet ENOSYS if the fs cannot implement any COW, and it isn't
> possible for userspace to duplicate the semantics by explicit copying?

	The point-in-time of the snapshot is what's important here.

> Do we say anything about attribute changes triggering COW or not, or
> leave it fs-dependent?  Given 3) fs-dependent makes sense, but it's
> nice to know in advance if { reflink -R old_tree saved_tree; chmod -R
> a-w saved_tree } will be as expensive as copying or as cheap as linking.

	"Shares the data extents of the source file".  I should hope
that chmod doesn't require copying out all the data.

Joel

-- 

Life's Little Instruction Book #267

	"Lie on your back and look at the stars."

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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux