LVM in default filesystem layout

[Josh Boyer]

On Tue, May 5, 2015 at 9:04 AM, Ray Strode <rstrode at redhat.com> wrote:
> Hi,
>
>> That is true, but it's beside the point.
> You're right that it's beside the point, but it's an additional, related, point worth discussing.
>
>> Throwing out device mapper just because LVM is built on top of it seems pretty silly.
> Hang on, current defaults:
>
> 1) LVM
> 2) No encryption
>
> This thread started with proposing changing 1.  If we do that without changing 2, then we won't
> want to use device mapper by default anymore. I'm sure you agree with that statement, and don't
> think it's silly. I'm not saying throwing device mapper out because LVM is built on it, I'm saying
> device mapper is a means to an end. If that end is no longer an end goal for us then we can get
> rid of device mapper.

I think it would be better phrased as "we could default to standard
partitioning."  Honestly, while I agree with your listed defaults, I
think disk encryption is common enough that we will not be able to
ignore it and get rid device mapper in F23.  (And personally, I don't
think we'd "get rid" of it in any case.  It would simply not be used
by default.)

> If we also want to change 2) no encryption, then there's the question of how to get there and that's
> another discussion worth having.  maybe device mapper is the answer, and maybe that's okay.  I'm
> just saying device mapper is extra complexity and if we can get rid of it, great.

Well, the current sub-thread is all about using ext4 encryption, which
is basically changing 2.

> Of course, I'd rather btrfs was ready, but I guess that's not a possibility near-term or mid-term.

And it's a great example of why we don't immediately default to using
something shiny and new just because it exists.  Btrfs is neither
shiny or new at this point, and we look at it every release and
discuss it with upstream and it still isn't ready to be default.

>> You guys are sure excited to dump something that is proven to work
>> (and allows flexibility in the filesystem on top of it) for something
>> new and shiny
> It doesn't have a perfect track record... In the past it's broken journaling and TRIM.

This is true.  However, those bugs have been fixed.  Ext4 encryption
has no track record at all.  I'd rather not hold every possible bug
that a component has had against it forever as justification for
switching to something that likely still has bugs itself and is
completely new.

josh