On Tue, Jun 12, 2007 at 03:53:03PM -0400, Mike Snitzer wrote: > On 6/12/07, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > >Hello everyone, > > > >After the last FS summit, I started working on a new filesystem that > >maintains checksums of all file data and metadata. Many thanks to Zach > >Brown for his ideas, and to Dave Chinner for his help on > >benchmarking analysis. > > Chris, > > Given the substantial work that you've already put into btrfs and the > direction you're Todo list details; it feels as though Btrfs will > quickly provide the features that only Sun's ZFS provides. > > Looking at your Btrfs benchmark and design pages it is clear that > you're motivation is a filesystem that addresses modern concerns > (performance that doesn't degrade over time, online fsck, fast offline > fsck, data/metadata checksums, unlimited snapshots, efficient remote > mirroring, etc). There is still much "Todo" but you've made very > impressive progress for the first announcement! > > I have some management oriented questions/comments. > > 1) > Regarding the direction of Btrfs as it relates to integration with DM. > The allocation policies, the ease of configuring DM-based > striping/mirroring, management of large pools of storage all seems to > indicate that Btrfs will manage the physical spindles internally. > This is very ZFS-ish (ZFS pools) so I'd like to understand where you > see Btrfs going in this area. There's quite a lot of hand waving in that section. What I'd like to do is work closely with the LVM/DM/MD maintainers and come up with something that leverages what linux already does. I don't want to rewrite LVM into the FS, but I do want to make better use of info about the underlying storage. > > Your initial benchmarks were all done ontop of a single disk with an > LVM stack yet your roadmap/todo and design speaks to a tighter > integration of the volume management features. So long term is > traditional LVM/MD functionality to be pulled directly into Btrfs? > > 2) > The Btrfs notion of subvolumes and snapshots is very elegant and > provides for a fluid management of the filesystem system data. It > feels as though each subvolume/snapshot is just folded into the parent > Btrfs volumes' namespace. Was there any particular reason you elected > to do this? I can see that it lends itself to allowing snapshots of > snapshots. If you could elaborate I'd appreciate it. > Yes, I wanted snapshots to be writable and resnapshottable. It also lowers the complexity to keep each snapshot as a subvolume/tree. subvolumes are only slightly more expensive than a directory. So, even though a subvolume is a large grained unit for a snapshot, you can get around this by just making more subvolumes. > In practice subvolumes and/or snapshots appear to be implicitly > mounted upon creation (refcount of parent is incremented). Is this > correct? For snapshots, this runs counter to mapping the snapshots' > data into the namespace of the origin Btrfs (e.g. with a .snapshot > dir, but this is only useful for read-only snaps). Having snapshot > namespaces in terms of monolithic subvolumes puts a less intuitive > face on N Btrfs snapshots. The history of a given file/dir feels to > be lost with this model. That's somewhat true, the disk format does have enough information to show you that history, but cleanly expressing it to the user is a daunting task. > > Aside from folding snapshot history into the origin's namespace... It > could be possible to have a mount.btrfs that allows subvolumes and/or > snapshot volumes to be mounted as unique roots? I'd imagine a bind > mount _could_ provide this too? Anyway, I'm just interested in > understanding the vision for managing the potentially complex nature > of a Btrfs namespace. One option is to put the real btrfs root into some directory in (/sys/fs/btrfs/$device?) and then use tools in userland to mount -o bind outside of that. I wanted to wait to get fancy until I had a better idea of how people would use the feature. > > Thanks for doing all this work; I think the Linux community got a much > needed shot in the arm with this Btrfs announcement. > Thanks for the comments. -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
