Plans for BTRFS in Fedora

Peter Jones 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
encrypted volumes:

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
      encryption:
      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.

-- 
        Peter

Computers don't make errors.  What they do, they do on purpose.
		-- Dale


More information about the devel mailing list