[lkml]   [2007]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
    On Tue, Jun 12, 2007 at 03:53:03PM -0400, Mike Snitzer wrote:
    > On 6/12/07, Chris Mason <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-12 22:19    [W:0.026 / U:42.732 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site