Plans for BTRFS in Fedora

[Josef Bacik]

On Tue, Feb 22, 2011 at 5:07 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Tue, 22.02.11 14:51, Josef Bacik (josef at toxicpanda.com) wrote:
>
>> Hello,
>>
>> So we're getting close to having a working fsck tool so I wanted to
>> take the opportunity to talk about the future of BTRFS in Fedora.
>> Coming up in F15 we're going to have the first release of Fedora where
>> we don't need the special boot option to have the ability to format
>> you filesystem as BTRFS.  This is in hopes that we can open it up for
>> wider testing before possibly making it the default filesystem.  I
>> realize we're in the early stages of F15, but since filesystems are
>> big and important I'd like to get an idea of the amount of work that
>> needs to still be done to get BTRFS in shape for being Fedora's
>> default filesystem.  So here are my goals
>>
>> 1) Fedora 16 ships with BTRFS as the default root filesystem.
>
> Hmm, what are your plans regarding hierarchy layout for this?
>
> My hope is that one day we can ship a read-only root dir by default, or
> more specifically a btrfs file system with three subvolumes in it: one
> read-only one mounted to /, and two writable ones mounted to /home and
> /var, with /tmp mounted from tmpfs.
>

Yeah the hope is to separate out various things into different
subvolumes so we can have things that can be independently
snapshottable things.

> We came a long way with supporting read-only root dirs and it should
> mostly work now. In F15 for example /etc/mtab is a symlink, and even
> smaller stuff like /etc/nologin got moved to /var/run, to make write
> accesses to /etc unnecessary during normal operation. /etc/resolv.conf
> is the only thing often updated that's left, but with NM using dnsmasq
> it's static too.
>
> By using btrfs subvolumes doing this kind of seperation into writable
> and non-writable subtrees we don't have to think anymore about the sizes
> for those file systems at install time, since they all live in the same
> fs.
>
> If this is adopted package managers and system configuration UIs would
> need to invoke "mount / -o rw,remount" before doing their work.
>
> So, I'd like to see this implemented one day, maybe the adoption of
> btrfs is the right time to push this through too?
>
> I have not filed a feature page for this, as I am not sure I want to
> push this on F16, and I don't even know if people in general are onboard
> with this idea. The benefits of this are mostly security and robustness
> since we know that the actual subvolume the OS is booted from is always
> in a consistent state during operation and cannot normally be
> changed. And of course, we get all kind of magic by doing this because
> we can easily use snapshots to roll back system upgrades while leaving
> /home completely untouched.
>
> Sorry for hijacking your thread like this,
>

It's cool, just hilights all the cool stuff we can do with BTRFS :).  Thanks,

Josef