On Tue, 22.02.11 14:51, Josef Bacik (josef@xxxxxxxxxxxxxx) 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. 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, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
