Hi, So I just noticed that an a fresh install system I did of the latest FW22 beta the filesystem gets set up with LVM. I thought this was one of the changes we had done to the Workstation compared to the server image for instance, to not use LVM?
If we haven't done so already I think we should since we don't really have any UI tools for editing LVM partitions (that said I realize it might be to big a change to push in last minute for 22, so at least for FW23.
Christian
On Mon, May 4, 2015 at 10:24 PM, Christian Schaller cschalle@redhat.com wrote:
Hi, So I just noticed that an a fresh install system I did of the latest FW22 beta the filesystem gets set up with LVM. I thought this was one of the changes we had done to the Workstation compared to the server image for instance, to not use LVM?
No it has been discussed and stayed as is ... and yes I agree that LVM makes little to no sense on desktops or even laptops (the latter in general only have one disc .. ).
On May 4, 2015 2:58 PM, "drago01" drago01@gmail.com wrote:
On Mon, May 4, 2015 at 10:24 PM, Christian Schaller cschalle@redhat.com
wrote:
Hi, So I just noticed that an a fresh install system I did of the latest
FW22 beta the filesystem gets set up with LVM.
I thought this was one of the changes we had done to the Workstation
compared to the server image for instance, to not use LVM?
No it has been discussed and stayed as is ... and yes I agree that LVM makes little to no sense on desktops or even laptops (the latter in general only have one disc .. ). --
I've seen people get themselves into tricky partitioning layout situations - especially on non-GPT systems - and the flexibility of LVM made it possible for them to install Fedora. Sometimes they did it to themselves, sometimes it's from the OEM. I suspect with admittedly no hard data that LVM as default transparently handled many, many situations where without LVM, relatively complex manual partitioning would be required.
Users that dual boot with Windows benefit if their partition state is suboptimal. Users that play with multiple distros on bare metal benefit from flexibility and segregation. I'm not sure who benefits from removing it, aside from folks that decide to only use gnome-disks for filesystem and partition management. This multiboot crowd is your mindshare generator, try to make it easy for them.
--Pete
I've had the opposite experience. I've never figured out how to multiboot after installing Fedora with LVM, since other distros' installers just can't handle it, nor do any standard partition management tools. I've no doubt LVM is great if you're familiar with how it works, but I have no intention of taking the time to figure out the different command line tools, nor do I plan to install another disk management application when we already have one part of our core OS.
On Tue, 2015-05-05 at 09:45 -0600, Pete Travis wrote:
I'm not sure who benefits from removing it, aside from folks that decide to only use gnome-disks for filesystem and partition management. This multiboot crowd is your mindshare generator, try to make it easy for them.
Um, I think we should indeed assume that folks use only GNOME Disks for filesystem and partition management... if we aren't prepared to make that assumption, we shouldn't be installing it by default.
The other common tool is gparted, which can't handle LVM either. I think I tried KDE's partition manager once and it had similar problems, but don't remember for sure.
I think it's important for LVM to be an option in the installer, for users who find it useful. But I see a very compelling case to use standard partitions by default when disk encryption is not selected. (On the other hand, we really ought to have full disk encryption by default....)
Michael
On May 5, 2015 10:35 AM, "Michael Catanzaro" mcatanzaro@gnome.org wrote:
I've had the opposite experience. I've never figured out how to multiboot after installing Fedora with LVM, since other distros' installers just can't handle it, nor do any standard partition management tools.
Can you give me some examples of other distro installers and layouts they couldn't handle? Just for my own edification, I have a WIP multiboot guide.
I've no doubt LVM is great if you're familiar with how it works, but I have no intention of taking the time to figure out the different command line tools, nor do I plan to install another disk management application when we already have one part of our core OS.
On Tue, 2015-05-05 at 09:45 -0600, Pete Travis wrote:
I'm not sure who benefits from removing it, aside from folks that decide to only use gnome-disks for filesystem and partition management. This multiboot crowd is your mindshare generator, try to make it easy for them.
Um, I think we should indeed assume that folks use only GNOME Disks for filesystem and partition management... if we aren't prepared to make that assumption, we shouldn't be installing it by default.
The other common tool is gparted, which can't handle LVM either. I think I tried KDE's partition manager once and it had similar problems, but don't remember for sure.
I think it's important for LVM to be an option in the installer, for users who find it useful. But I see a very compelling case to use standard partitions by default when disk encryption is not selected. (On the other hand, we really ought to have full disk encryption by default....)
Michael
My sense is that there would be less *need* for partition and filesystem management tools with LVM, but to be fair, I'm the guy that suspects that 90% of the people using gparted do so because "I like /home to be on /dev/sda3" or some other arbitrary personal preference.
I can *definitely* say I've encountered a bunch of situations where the user had an MBR drive with valuable data on the fourth partition. Anaconda won't (wouldn't?) create an extended partition anywhere else, so they have room for one, maybe two partitions. They *want* boot, root, swap, home, maybe more. The installer doesn't really explain the inherent restrictions in this situation, and arguably should not. With LVM, this layout is probably fine; without, you are going to need partitioning tools and expertise to even start the installation. The complex layer of storage abstraction is actually exposing less complexity to the user, in this case.
+1 for encryption by default, although I'll defer to others on the ideal implementation. That change would be marketable and valuable to end users, looking forward to the F23 Change proposal for it.
--Pete
----- Original Message -----
From: "Pete Travis" lists@petetravis.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Tuesday, May 5, 2015 4:27:21 PM Subject: Re: LVM in default filesystem layout
On May 5, 2015 10:35 AM, "Michael Catanzaro" < mcatanzaro@gnome.org > wrote:
(On the other hand, we really ought to have full disk encryption by default....)
+1 for encryption by default, although I'll defer to others on the ideal implementation. That change would be marketable and valuable to end users, looking forward to the F23 Change proposal for it.
This should probably be its own thread, but I'll note that the current state of encryption on Workstation is less than ideal (speaking as someone using it). Offline updates with encrypted partitions means re-entering the password twice; once to enter the offline-update mode and once to boot again afterwards. This is a bigger inconvenience than it sounds.
I think openSUSE at least can't handle dual-boot with Fedora LVM, and its installer attempts to wipe away Fedora instead of installing nicely alongside it like it does for other Linux distros. But it's been a while since I've tried it, so it's possible I am misremembering.
On Tue, 2015-05-05 at 14:27 -0600, Pete Travis wrote:
My sense is that there would be less *need* for partition and filesystem management tools with LVM
You have strong points in favor of LVM.
I guess the most significant downside is the very poor support in GNOME Disks.
Hi
On Tue, May 5, 2015 at 5:08 PM, Michael Catanzaro wrote:
You have strong points in favor of LVM.
I guess the most significant downside is the very poor support in GNOME Disks.
It seems to be that the better path forward is to default to encryption on atleast laptops and add support for LVM to GNOME Disks rather than moving away from LVM with no real plan to handle encryption without it
Rahul
----- Original Message -----
From: "Rahul Sundaram" metherid@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Tuesday, May 5, 2015 5:27:09 PM Subject: Re: LVM in default filesystem layout
Hi
On Tue, May 5, 2015 at 5:08 PM, Michael Catanzaro wrote:
You have strong points in favor of LVM.
I guess the most significant downside is the very poor support in GNOME Disks.
It seems to be that the better path forward is to default to encryption on atleast laptops and add support for LVM to GNOME Disks rather than moving away from LVM with no real plan to handle encryption without it
I am not sure if I am missing something here, but I just did a fresh install today of the Fedora Workstation 22 beta, I choose not to have the disk set up with LVM, yet I asked for encryption, as far as I can tell it works just fine at least I get asked for my decryption key upon boot.
Christian
Hi
On Tue, May 5, 2015 at 6:52 PM, Christian Schaller wrote:
I am not sure if I am missing something here, but I just did a fresh install today of the Fedora Workstation 22 beta, I choose not to have the disk set up with LVM, yet I asked for encryption, as far as I can tell it works just fine at least I get asked for my decryption key upon boot.
Yes. I confirmed this last night. Thanks
Rahul
On Tue, May 5, 2015 at 5:27 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Tue, May 5, 2015 at 5:08 PM, Michael Catanzaro wrote:
You have strong points in favor of LVM.
I guess the most significant downside is the very poor support in GNOME Disks.
It seems to be that the better path forward is to default to encryption on atleast laptops and add support for LVM to GNOME Disks rather than moving away from LVM with no real plan to handle encryption without it
As noted earlier in the thread, disk encryption does not require nor even use LVM. It uses device mapper (specifically dm-crypt).
josh
On Tue, 2015-05-05 at 01:17 +0200, Lars Seipel wrote:
On Mon, May 04, 2015 at 04:24:13PM -0400, Christian Schaller wrote:
If we haven't done so already I think we should since we don't really have any UI tools for editing LVM partitions
Palimpsest/gnome-disk-utility used to have LVM support. What happened to it?
It was removed three years ago, when the app was rewritten from scratch.
On Tue, May 5, 2015 at 12:17 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, May 04, 2015 at 04:24:13PM -0400, Christian Schaller wrote:
If we haven't done so already I think we should since we don't really have any UI tools for editing LVM partitions
Palimpsest/gnome-disk-utility used to have LVM support. What happened to it?
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
----- Original Message -----
On Tue, May 5, 2015 at 12:17 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, May 04, 2015 at 04:24:13PM -0400, Christian Schaller wrote:
If we haven't done so already I think we should since we don't really have any UI tools for editing LVM partitions
Palimpsest/gnome-disk-utility used to have LVM support. What happened to it?
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
On a workstation or laptop, LVM's main use is to encrypt the disks. Ext4 gained support for that, which could allow us to encrypt by default, without the need for LVM at all: https://bugzilla.redhat.com/show_bug.cgi?id=1217517
On Tue, May 5, 2015 at 12:47 PM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On Tue, May 5, 2015 at 12:17 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, May 04, 2015 at 04:24:13PM -0400, Christian Schaller wrote:
If we haven't done so already I think we should since we don't really have any UI tools for editing LVM partitions
Palimpsest/gnome-disk-utility used to have LVM support. What happened to it?
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
On a workstation or laptop, LVM's main use is to encrypt the disks.
huh? you don't need lvm for disk encryption.
Hi,
On Tue, May 5, 2015 at 12:47 PM, Bastien Nocera bnocera@redhat.com wrote:
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
On a workstation or laptop, LVM's main use is to encrypt the disks.
huh? you don't need lvm for disk encryption.
Well, you do need device mapper, for how we do encryption, though, and of course, you can't have LVM without device mapper.
I think getting rid of device mapper is a good, related, goal, too. Both LVM and device mapper add layers of complexity that, while useful in some contexts, aren't really necessary in a lot of common workstation cases.
--Ray
On Tue, May 5, 2015 at 2:32 PM, Ray Strode rstrode@redhat.com wrote:
Hi,
On Tue, May 5, 2015 at 12:47 PM, Bastien Nocera bnocera@redhat.com wrote:
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
On a workstation or laptop, LVM's main use is to encrypt the disks.
huh? you don't need lvm for disk encryption.
Well, you do need device mapper, for how we do encryption, though, and of course, you can't have LVM without device mapper.
Well yeah but the point is "you don't need LVM for encryption" not "you don't need device mapper for LVM".
On Tue, May 5, 2015 at 8:32 AM, Ray Strode rstrode@redhat.com wrote:
Hi,
On Tue, May 5, 2015 at 12:47 PM, Bastien Nocera bnocera@redhat.com wrote:
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
On a workstation or laptop, LVM's main use is to encrypt the disks.
huh? you don't need lvm for disk encryption.
Well, you do need device mapper, for how we do encryption, though, and of course, you can't have LVM without device mapper.
That is true, but it's beside the point. Throwing out device mapper just because LVM is built on top of it seems pretty silly.
I think getting rid of device mapper is a good, related, goal, too. Both LVM and device mapper add layers of complexity that, while useful in some contexts, aren't really necessary in a lot of common workstation cases.
If you read the article comments, the _author_ of the ext4 encryption work says for single user laptops he would recommend sticking with dm-crypt for now.
http://lwn.net/Articles/640015/
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. Let's back off for a bit and give this time to mature.
josh
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.
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.
Of course, I'd rather btrfs was ready, but I guess that's not a possibility near-term or mid-term.
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.
--Ray
On Tue, May 5, 2015 at 9:04 AM, Ray Strode rstrode@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:
- LVM
- 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
----- Original Message -----
On Tue, May 5, 2015 at 9:04 AM, Ray Strode rstrode@redhat.com wrote:
<snip>
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.
ext4 encryption is what's used in Android Lollipop, I believe.
On Tue, May 5, 2015 at 7:58 AM, drago01 drago01@gmail.com wrote:
On Tue, May 5, 2015 at 12:47 PM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On Tue, May 5, 2015 at 12:17 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, May 04, 2015 at 04:24:13PM -0400, Christian Schaller wrote:
If we haven't done so already I think we should since we don't really have any UI tools for editing LVM partitions
Palimpsest/gnome-disk-utility used to have LVM support. What happened to it?
blivet-gui works OK for some bits of LVM, it's a frontend for the same library used in anaconda, it depends on what functionality the Workstation people expect though, it doesn't for example support the use of things like LVM snapshots, roll back of snapshots etc.
On a workstation or laptop, LVM's main use is to encrypt the disks.
huh? you don't need lvm for disk encryption.
Right. dm-crypt is what is most common.
So I think hanging our encryption efforts on ext4 encryption at this point is premature. The comments in the article Bastien linked to are actually pretty good, and Ted and Michael spent time clarifying and answering questions. For a single user laptop, dm-crypt performance is likely going to be on-par with ext4 encryption, or at least close enough to not have us jumping on ext4 immediately. For multi-user systems, ext4 is a slightly more intriguing option since you don't have one single key for the whole system. But that tends to not be the user base Workstation is targeting.
At the moment this is all moot anyway, because the feature just got merged with 4.1 and it's disabled in the Fedora kernel for now. I'm not even sure userspace is ready to leverage this yet either.
josh
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Christian Schaller -
drago01 -
Josh Boyer -
Lars Seipel -
Michael Catanzaro -
Pete Travis -
Peter Robinson -
Rahul Sundaram -
Ray Strode -
Stephen Gallagher