#964 Change default autopart strategy back from raw ext4 to LVM #870207
Closed None Opened 9 years ago by johannbg.

The storage people wereń't paying attention for months and now they want things back as they were before in the installer in any case this is your headache and we are past freeze.

Preliminary testing shows it works but we want to expose this to wider audience but it's awkward to put the change into anaconda if we might then have to take it out again we would just be wasting everybody's time and resources building anaconda packages and updates and karmaing them stuffing them into smoke test etc. etc. etc.

The sooner you reach decision the better it is for everybody...

Just to amplify a bit, when johann says "in any case this is your headache and we are past freeze"...

We kinda have two questions, 'does Fedora in theory think it would be right to go back to LVM-by-default for F18?', and if the answer to that is 'yes', 'is it safe to do so at this point for F18 Beta?'

We can answer the second question as part of the NTH process, but the first seems to be pretty controversial as things stand and Johann reckons that FESCo should make a call on it. That seems pretty reasonable to me too. We seem to have two sides on that question which aren't backing down and no clear consensus about who's right.

The bug is https://bugzilla.redhat.com/show_bug.cgi?id=870207 , to provide a convenient hyperlink.

IMHO, defaulting to LVM has always been a bad idea, it hurts performance, several partition manipulation tools can't deal with it, etc.

I realize the urgency of this hasn't been made clear, so let's make it clear.

Beta go/no-go is scheduled for 11-01. We need a decision on this over the weekend or on Monday. If no decision is made by then I don't see any option but to stick with the current behaviour (ext4), we just cannot go poking this code two days before we sign off on the Beta, no matter how theoretically safe it is.

I vote +1 to change the default back to LVM as the change of the default was not properly communicated and as we will be changing the default FS to btrfs in future release (in F19 already?), where it will be much more proper to drop the LVM by default autopart strategy. Otherwise we will be changing the default to no-LVM without proper consensus reached just for one release (F18).

It was also not communicated that end users cant unhash LVM from the autopart in the newUI which is a regression from F17 and also was not properly communicated and BTRFS needs to go through the feature process like everything else and be accepted so it's a bit to early making decision based upon the fact that it will be accepted in F19 as the default filesystem for the distribution even thou it seems that it has already been decided from the "storage community" that it will be the case...

I guess Anaconda has still a lot of work to do before the release, therefore I'm not sure if our votes for adding LVM back can change something.

I'm curious the outcome of the smoketesting asked for last week with LVM enabled? Any big problems found?

If not, I am for changing it back to lvm by default for f18. Later releases can revist this in their cycles.

I'll try and get other FESCo folks to vote here and see if we can wrap this up today

mmaslano: the change, as described on the bug, is a two-liner. It is not an issue in terms of code.

kevin: so far the testing has not exposed any issues.

LVM does have benefits on every system:

  • Even on a laptop, having LVM allows us to only have one encrypted partition (the LVM PV) instead of two (/ and swap) or perhaps three (/, /home, swap). One encrypted partition instead of two or more means and only one 1-second delay on boot instead of two or more, and more importantly no risk of inconsistent passphrases.
  • If you find out you need LVM, there's no practical way to add it to an already installed system; so it is better to add it in advance.

OTOH I haven't seen a significant reason to disable it. (Is there really a significant performance difference?)

Given the lack of previous consensus to disable LVM, tentative ack by David Lehman ([https://bugzilla.redhat.com/show_bug.cgi?id=870207#c31]) and positive test results so far, +1 to enabling LVM by default again.

mitr: I'd expect encrypting only /home is the most common 'selective encryption' case. /home is most likely to contain sensitive data, after all.

So, I see +4 from fesco folks for changing the default back to lvm.

Would the other fesco folks please vote?

I see only +3 votes.

I agree with mitr points. It would be really strange if we re-enable lvm back into F-19 as default and missed it in F-18.

+1 from me

Number of fesco members 9

tmraz +1 comment 9

" I'm curious the outcome of the smoketesting asked for last week with LVM enabled? Any big problems found?
If not, I am for changing it back to lvm by default for f18. "

No big problems where discovered during testing which means kevin +1 comment 12

limb +1 comment 13

mitr +1 comment 15

mmaslano +1 comment 15

Total number of +5

Total number to reach majority = 5

which means majority achieved for reverting back to go back to LVM-by-default for F18.

This ticket can be closed now.

Login to comment on this ticket.