[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 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.
    > The basic list of features looks like this:
    > * Extent based file storage (2^64 max file size)
    > * Space efficient packing of small files
    > * Space efficient indexed directories
    > * Dynamic inode allocation
    > * Writable snapshots
    > * Subvolumes (separate internal filesystem roots)
    > - Object level mirroring and striping
    > * Checksums on data and metadata (multiple algorithms available)
    > - Strong integration with device mapper for multiple device support
    > - Online filesystem check
    > * Very fast offline filesystem check
    > - Efficient incremental backup and FS mirroring
    > The ones with marked with * are mostly working, and the others are on
    > my todo list. There are more details on the FS design, some benchmarks
    > and download links here:
    > The current status is a very early alpha state, and the kernel code
    > weighs in at a sparsely commented 10,547 lines. I'm releasing now in
    > hopes of finding people interested in testing, benchmarking,
    > documenting, and contributing to the code.
    > I've gotten this far pretty quickly, and plan on continuing to knock off
    > the features as fast as I can. Hopefully I'll manage a release every
    > few weeks or so. The disk format will probably change in some major way
    > every couple of releases.
    > The TODO list has some critical stuff:
    > * Ability to return -ENOSPC instead of oopsing
    > * mmap()ed writes
    > * Fault tolerance, (EIO, bad metadata etc)
    > * Concurrency. I use one mutex for all operations today
    > * ACLs and extended attributes
    > * Reclaim dead roots after a crash
    > * Various other bits from the feature list above
    > And finally, here's a quick and dirty summary of the FS design points:
    > * One large Btree per subvolume
    > * Copy on write logging for all data and metadata
    > * Reference count snapshots are the basis of the transaction
    > system. A transaction is just a snapshot where the old root
    > is immediately deleted on commit
    > * Subvolumes can be snapshotted any number of times
    > * Snapshots are read/write and can be snapshotted again
    > * Directories are doubly indexed to improve readdir speeds
    > So, please give it a try or a look and let me know what you think.


    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.

    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.

    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?

    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.

    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.

    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.

    Thanks for doing all this work; I think the Linux community got a much
    needed shot in the arm with this Btrfs announcement.

    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 21:57    [W:0.032 / U:36.764 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site