Plans for BTRFS in Fedora
pjones at redhat.com
Wed Feb 23 14:07:55 UTC 2011
On 02/22/2011 10:25 PM, Jon Masters wrote:
> On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
>> 2) Fedora 16 ships without LVM as the volume manager and instead use
>> BTRFS's built in volume management, again just for the default.
> In my personal opinion, this is a poor design decision. Yes, BTRFS can
> do a lot of volume-y things, and these are growing by the day, but I
> don't want my filesystem replacing a full volume manager and I am
> concerned that this will lead to less testing and exposure to full LVM
> use within the Fedora community. Instead, I'd like to counter-propose
> that everything stay exactly as it is, with users being able to elect to
> switch to BTRFS (sub)volumes if they are interested in doing so.
I think this is more than a little bit over the top, but there are some
legitimate concerns we do need to keep track of and figure out solutions
to. Off the top of my head, we need to figure out what we're doing with
1) can btrfs do encrypted volumes? Or, somewhat weirder but possibly better,
encrypted volumes with non-encrypted subvolumes?
a) if encrypted volumes but not plaintext subvolumes, then we need /boot
split out to a separate physical partition, maybe
b) if it can do encrypted subvolumes of non-encrypted volumes, we
could make a /boot and a /sysroot and mount /sysroot as / I guess
c) if no encrypted volumes, or if that functionality won't land at the
same time as the basic parts, then we need to talk about UI for disk
I) keeping lvm when "encrypt data" is checked in the anaconda UI,
so we can continue to use luks on a VG in those cases.
II) it may be worth investigating identifying machine classes during
installation and varying the defaults based on them. We talk about
doing this every 3 or 4 releases for various reasons and usually
decide it's a terrible idea and do something else.
> Should the switch to BTRFS by default happen, this will be one more
> thing I will have to fix immediately during installation. The list grows
> longer and longer over time - please don't make this change.
I think you're confusing necessity and desire here.
Computers don't make errors. What they do, they do on purpose.
More information about the devel