Re: New reflink(2) syscall

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

 



On Tue, 2009-05-05 at 10:13 -0700, Joel Becker wrote:
> On Tue, May 05, 2009 at 12:56:58PM -0400, Chris Mason wrote:
> > On Tue, 2009-05-05 at 09:47 -0700, Joel Becker wrote:
> > > 	Because then you have to change the entire security structure,
> > > and you aren't a snapshot anymore.
> > 
> > I won't argue with the security part, but the snapshot part could just
> > as easily be defined by the data and not the inode.
> 
> 	In ZFS/btrfs/WAFL/disk array snaps, if you go back to a snap
> does the selinux context or acls or equivalent appear different?  I don't
> think so, and I expect people would be really upset if they had to know
> all the restorecon/acl-fu to get it right.

So a btrfs snapshot is a whole subvolume (directory tree), and if you
haven't changed the snapshot it'll be the same.

For the btrfs clone ioctl, you're explicitly snapshotting only the data.
The inode permissions, acls etc are userland's problem.

Both ways have benefits, and you can get from the reflink one to any
other form pretty easily after the reflink call.

-chris




--
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