Excerpts from Josef Bacik's message of 2010-12-01 09:21:36 -0500: > 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. Thanks for writing this up. > === What do we do? === > > This is where I expect to see the most discussion. Here is what I want to do > > 1) Scrap the 256 inode number thing. Instead we'll just put a flag in the inode > to say "Hey, I'm a subvolume" and then we can do all of the appropriate magic > that way. This unfortunately will be an incompatible format change, but the > sooner we get this adressed the easier it will be in the long run. Obviously > when I say format change I mean via the incompat bits we have, so old fs's won't > be broken and such. If they don't have inode number 256, what inode number do they have? I'm assuming you mean the subvolume is given an inode number in the parent directory just like any other dir, but this doesn't get rid of the duplicate inode problem. I think it ends up making it less clear, but I'm open to suggestions ;) We could give each subvol a different devt, which is something Christoph had asked about as well. -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
