Re: What to do about subvolumes?

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

 



On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
> On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
> > Hello,
> > 
> > Various people have complained about how BTRFS deals with subvolumes recently,
> > specifically the fact that they all have the same inode number, and there's no
> > discrete seperation from one subvolume to another.  Christoph asked that I lay
> > out a basic design document of how we want subvolumes to work so we can hash
> > everything out now, fix what is broken, and then move forward with a design that
> > everybody is more or less happy with.  I apologize in advance for how freaking
> > long this email is going to be.  I assume that most people are generally
> > familiar with how BTRFS works, so I'm not going to bother explaining in great
> > detail some stuff.
> > 
....
> > are things that cannot be fixed now.  Some of these changes will require
> > incompat format changes, but it's either we fix it now, or later on down the
> > road when BTRFS starts getting used in production really find out how many
> > things our current scheme breaks and then have to do the changes then.  Thanks,
> > 
> 
> So now that I've actually looked at everything, it looks like the semantics are
> all right for subvolumes
> 
> 1) readdir - we return the root id in d_ino, which is unique across the fs
> 2) stat - we return 256 for all subvolumes, because that is their inode number
> 3) dev_t - we setup an anon super for all volumes, so they all get their own
> dev_t, which is set properly for all of their children, see below

A property of NFS fileshandles is that they must be stable across
server reboots. Is this anon dev_t used as part of the NFS
filehandle and if so how can you guarantee that it is stable?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
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