On Tue, 22.02.11 14:51, Josef Bacik (josef(a)toxicpanda.com) wrote:
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.
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
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,
Lennart Poettering - Red Hat, Inc.