On Tue, Jun 12, 2007 at 03:53:03PM -0400, Mike Snitzer wrote:
> On 6/12/07, Chris Mason <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
