Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, Oct 26, 2012 at 1:24 AM, Robyn Bergeron rberg...@redhat.com wrote: I am under the impression that we've been testing with/without LVM anyway, both scenarios? In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there Which documentation? FS directly on a partition has way more documentation then anything else ... it is what the rest of the world is using. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/26/2012 02:53 AM, Adam Williamson wrote: The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default_now_, for one release (or possibly two), only to change it again shortly. Where did they get that F19 will be default to BTRFS? Have they just decided that for FESCO and the project in whole? And last time I spoke with Josef he mentioned ( which admittedly was a while back ) that it probably would not be properly ready until F20 JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, Oct 26, 2012 at 6:23 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 10/26/2012 02:53 AM, Adam Williamson wrote: The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default_now_, for one release (or possibly two), only to change it again shortly. Where did they get that F19 will be default to BTRFS? He said aiming. Have they just decided that for FESCO and the project in whole? Nothing has been decided. I would expect these Storage People to go through the Feature process like everyone else. Calm down. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, 2012-10-26 at 10:23 +, Jóhann B. Guðmundsson wrote: On 10/26/2012 02:53 AM, Adam Williamson wrote: The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default_now_, for one release (or possibly two), only to change it again shortly. Where did they get that F19 will be default to BTRFS? Have they just decided that for FESCO and the project in whole? And last time I spoke with Josef he mentioned ( which admittedly was a while back ) that it probably would not be properly ready until F20 No-one's decided anything, it's just the latest goal they're aiming for. It'll go through the feature process as always. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Importance of LVM (was Re: Partitioning criteria revision proposal)
On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/25/2012 08:26 PM, Adam Williamson wrote: On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our*original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent*current* arguments for keeping that default until we switch to btrfs-by-default. First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria Can we please stop messing around with the installer! JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 20:41 +, Jóhann B. Guðmundsson wrote: On 10/25/2012 08:26 PM, Adam Williamson wrote: On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria Can we please stop messing around with the installer! Like I said in the bug I also think it's pretty late to change this, but the change is in fact small and simple: the autopart code hasn't actually changed in newUI and has always had the ability to do both LVM and non-LVM layouts (in oldUI, remember, we gave you a checkbox to pick). All the patch does is change the default for the autopart algorithm, it's a two-liner: diff --git a/pyanaconda/ui/gui/spokes/storage.py b/pyanaconda/ui/gui/spokes/storage.py index 14ea404..6d7d9b6 100644 --- a/pyanaconda/ui/gui/spokes/storage.py +++ b/pyanaconda/ui/gui/spokes/storage.py @@ -337,8 +337,7 @@ class StorageSpoke(NormalSpoke, StorageChecker): self.data.autopart.encrypted = self.encrypted self.data.autopart.passphrase = self.passphrase -# no thanks, lvm -self.data.autopart.type = AUTOPART_TYPE_PLAIN +self.data.autopart.type = AUTOPART_TYPE_LVM self.clearPartType = CLEARPART_TYPE_NONE diff --git a/pyanaconda/ui/tui/spokes/storage.py b/pyanaconda/ui/tui/spokes/storage.py index c0a7cdd..b486657 100644 --- a/pyanaconda/ui/tui/spokes/storage.py +++ b/pyanaconda/ui/tui/spokes/storage.py @@ -229,8 +229,7 @@ class StorageSpoke(NormalTUISpoke): self.data.ignoredisk.onlyuse = self.selected_disks[:] self.data.clearpart.drives = self.selected_disks[:] -# no thanks, lvm -self.data.autopart.type = AUTOPART_TYPE_PLAIN +self.data.autopart.type = AUTOPART_TYPE_LVM if self.autopart: self.clearPartType = CLEARPART_TYPE_ALL and the code we're using is the same code we used and tested in all previous releases. So it's not actually a terribly scary change. On that basis I'm not horribly worried about doing it in practical terms, though I agree it would have been better to do it earlier. I'm about to post an updates.img to the bug you can use to test the change with TC6. I'm doing a first test of it right now and it seems to be working fine. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. What exactly does not hold anymore? Resizing partitions isn't that common and not the primary use of LVM (you can do it without it and most users won't). It is still pretty much useless (as in the extra features won't be used) for the average desktop / laptop installs. For most users all it does is slowing down the boot process (we should stop adding crap to the default boot process because someone might need it on some obscure case). Those who know about the extra features and want to use them will enable it anyway regardless on what we set as defaults. So no -1 on that. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 22:51 +0200, drago01 wrote: On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. What exactly does not hold anymore? Resizing partitions isn't that common and not the primary use of LVM (you can do it without it and most users won't). You can do it without LVM, but not as reliably (you're *more* likely to get into trouble resizing a raw ext4 partition than an LV) and with more limitations (the big one being you can't resize an ext4 partition from the front: so if you have a disk with 10GB / then 100GB /home, and you fill up /, you can't make /home smaller and use the additional space for /, because it can't be contiguous. All you can do is create a new partition after /home and bodge it up somehow, by mounting it as /var or something; much messier). 'most users won't' is hard to prove but likely true, but then, *some* users will, and isn't it nice that they have the ability to do it? It is still pretty much useless (as in the extra features won't be used) for the average desktop / laptop installs. They're neat features, though, and they're available, and _some_ people can use them, and people who don't use them aren't hurt (except see below). For most users all it does is slowing down the boot process (we should stop adding crap to the default boot process because someone might need it on some obscure case). Does LVM slow down boot significantly? Do you have numbers for that? I hadn't heard that factor cited in the debate so far. Could you add it to the bug if you have solid data? It'd be useful input. Those who know about the extra features and want to use them will enable it anyway regardless on what we set as defaults. It's somewhat harder to change in newUI than oldUI because there isn't just a checkbox for it, and I don't think the designers want there to be one. To change from the default (whatever the default is) you have to go through custom partitioning. Also, this doesn't catch the case of someone who's never used LVM, does an install of Fedora, notices that it uses LVM, and gets interested about it and finds out the neat stuff it can do. That's not a terribly unusual use case for Linux distros in general, is it? We all start out as newbies after all...I often find out about cool stuff 'by accident' in this way, just by stumbling across it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, Oct 25, 2012 at 11:09 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-10-25 at 22:51 +0200, drago01 wrote: On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. What exactly does not hold anymore? Resizing partitions isn't that common and not the primary use of LVM (you can do it without it and most users won't). You can do it without LVM, but not as reliably (you're *more* likely to get into trouble resizing a raw ext4 partition than an LV) and with more limitations (the big one being you can't resize an ext4 partition from the front: so if you have a disk with 10GB / then 100GB /home, and you fill up /, you can't make /home smaller and use the additional space for /, because it can't be contiguous. All you can do is create a new partition after /home and bodge it up somehow, by mounting it as /var or something; much messier). 'most users won't' is hard to prove but likely true, but then, *some* users will, and isn't it nice that they have the ability to do it? Yes but that can be said about pretty much anything. It is still pretty much useless (as in the extra features won't be used) for the average desktop / laptop installs. They're neat features, though, and they're available, and _some_ people can use them, and people who don't use them aren't hurt (except see below). For most users all it does is slowing down the boot process (we should stop adding crap to the default boot process because someone might need it on some obscure case). Does LVM slow down boot significantly? Do you have numbers for that? I hadn't heard that factor cited in the debate so far. Could you add it to the bug if you have solid data? It'd be useful input. I don't have current numbers but it adds a synchronisation point (i.e breaks a fully parallel bootup) let me just quote this (http://0pointer.de/blog/projects/blame-game.html): Let's have a closer look at the worst offender on this boot: a service by the name of udev-settle.service. So why does it take that much time to initialize, and what can we do about it? This service actually does very little: it just waits for the device probing being done by udev to finish and then exits. Device probing can be slow. [..] So, why is udev-settle.service part of our boot process? Well, it actually doesn't need to be. It is pulled in by the storage setup logic of Fedora: to be precise, by the *LVM*, RAID and Multipath setup script. These storage services have not been implemented in the way hardware detection and probing work today: they expect to be initialized at a point in time where all devices have been probed, so that they can simply iterate through the list of available disks and do their work on it. However, on modern machinery this is not how things actually work: hardware can come and hardware can go all the time, during boot and during runtime. For some technologies it is not even possible to know when the device enumeration is complete (example: USB, or iSCSI), thus waiting for all storage devices to show up and be probed must
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
I think it's way quite late in the cycle to talk about merits and drawbacks of LVM by default. It's quite late for discussing what is a better default. And that's why we should stick to the long term default, that means LVM. Personally I didn't like (maybe even hated) LVM when I started to work on Fedora. Now I like it. But that doesn't matter. The problem is that this issue was not properly discussed. There should have been a long thread on the lists. Different people should have posted their opinions. Measurements should have been made with regard to the boot time. FESCo should have posted their stance. Et cetera et cetera. The default was flipped to raw partitions in early builds of F18 Anaconda, and that was unfortunate, because it lacked a proper discussion and announcement (it was quite a surprise for QA). It is still (barely) time to flip the default back, to what it always was. But there's no way enough time to _start_ the discussion now. It would consume weeks and by that time Beta should be out. I think there are some LVM haters in the community who finally saw a chance to cleanse Fedora of this evil, and now will be very angry if someone wants to revert it. They might be wrong, they might be right. But I don't think this is the discussion we want to have now. That discussion should target Fedora 19. Now we should keep the defaults from previous Fedora versions. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, 2012-10-26 at 00:12 +0200, drago01 wrote: Also, this doesn't catch the case of someone who's never used LVM, does an install of Fedora, notices that it uses LVM, and gets interested about it and finds out the neat stuff it can do. That's not a terribly unusual use case for Linux distros in general, is it? We all start out as newbies after all...I often find out about cool stuff 'by accident' in this way, just by stumbling across it. He might also find find out that it is useless for him and that he cannot (easily) remove it without reinstalling. I am not saying LVM does not have use cases where it makes sense. I just don't think it makes sense as a default. I guess I just don't really get this. Maybe it comes from the fact that I know my computer is doing all sorts of stuff all the time that I don't 'need' it to do. But I don't really feel compelled to go and build a kernel with all the drivers I don't use taken out, and hack up udev not to probe things I don't care about, and and and... if something's happening that isn't benefiting me right at this second I don't feel some kind of compulsion to RIP IT OUT RIP OUT THE EVIL NOW. So someone finds their system is using LVM and they don't feel like taking advantage of any of LVM's specific benefits right now. Fine. What have they lost? Why would you be so terribly angry that you can't 'remove it'? I mean, ext4 probably has benefits I'm not using right now, but I'm not feeling compelled to switch my disks to something less capable... The performance point is likely worth bringing up in the bug, though. (Of course, invoking Lennart in any debate can have its own pitfalls :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, Oct 26, 2012 at 12:35 AM, Adam Williamson awill...@redhat.com wrote: On Fri, 2012-10-26 at 00:12 +0200, drago01 wrote: Also, this doesn't catch the case of someone who's never used LVM, does an install of Fedora, notices that it uses LVM, and gets interested about it and finds out the neat stuff it can do. That's not a terribly unusual use case for Linux distros in general, is it? We all start out as newbies after all...I often find out about cool stuff 'by accident' in this way, just by stumbling across it. He might also find find out that it is useless for him and that he cannot (easily) remove it without reinstalling. I am not saying LVM does not have use cases where it makes sense. I just don't think it makes sense as a default. I guess I just don't really get this. Maybe it comes from the fact that I know my computer is doing all sorts of stuff all the time that I don't 'need' it to do. But I don't really feel compelled to go and build a kernel with all the drivers I don't use taken out, and hack up udev not to probe things I don't care about, and and and... My point is that there is a cost of adding it. While the benefit for the majority of users is almost zero (messing with the system partitions is not a thing lots of people do after installation). We are pretty much the only distro that used it by default. if something's happening that isn't benefiting me right at this second I don't feel some kind of compulsion to RIP IT OUT RIP OUT THE EVIL NOW. That wasn't my point ... So someone finds their system is using LVM and they don't feel like taking advantage of any of LVM's specific benefits right now. Fine. What have they lost? See above (and the other post). Why would you be so terribly angry that you can't 'remove it'? I mean, ext4 probably has benefits I'm not using right now, but I'm not feeling compelled to switch my disks to something less capable... Because you don't gain much by using something less capable. The performance point is likely worth bringing up in the bug, though. (Of course, invoking Lennart in any debate can have its own pitfalls :) Done. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/25/2012 01:41 PM, Jóhann B. Guðmundsson wrote: On 10/25/2012 08:26 PM, Adam Williamson wrote: On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our*original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent*current* arguments for keeping that default until we switch to btrfs-by-default. First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria I am under the impression that we've been testing with/without LVM anyway, both scenarios? In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there Can we please stop messing around with the installer! JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 16:24 -0700, Robyn Bergeron wrote: First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria I am under the impression that we've been testing with/without LVM anyway, both scenarios? Sort of yes and sort of no. People have been testing LVM installs for sure; we've had bugs filed and fixed on it. But we haven't been testing LVM autopart in F18 because newUI doesn't actually let you; it doesn't let you pick 'LVM autopart' or 'non-LVM autopart' as oldUI did. If you do autopart you're stuck with raw ext4. As I said, though, it's the same code we used for F17 and before that all the way back to the storage rewrite, it was never taken out, so it seems unlikely it'd suddenly be badly broken. And indeed I did a couple of tests with the updates.img I put in the bug report and it seems to work fine. In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there Yeah, it's kind of a messy situation and you can argue it both ways :( On the one hand it's absolutely true we shouldn't be screwing about with the code at this point for Beta unless we really need to. On the other hand, all you say about the 'change to raw ext4 by default' really being the big change and it not having been properly proposed, discussed and documented is true; and we can't really 'just push this out to the next release' because once we do a stable release with raw ext4 by default, the whole situation has been changed, and now going back to LVM by default is the 'big change'. So it's really a bit of a mess. :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/25/2012 11:24 PM, Robyn Bergeron wrote: I am under the impression that we've been testing with/without LVM anyway, both scenarios? The installer has been defaulting to EXT4 up to this point there is no option to hash or unhash lvm as you could do in the oldUI in the newUI and custom partitioning has been more or less broken this whole time. The oldUI rendered ext4 vs lvm argument moot because it was equally easy/hard to disable/enable it for both parties. In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there I think you should focus on getting the feature process to actually define what it considers as an actual feature before you propose removing lvm as feature . From that same argumental stand point removing the functionality of disabling lvm as easily as it was in F17 should have been mentioned on the newUI feature page. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Oct 25, 2012, at 4:32 PM, Kamil Paral kpa...@redhat.com wrote: The default was flipped to raw partitions in early builds of F18 Anaconda, and that was unfortunate, because it lacked a proper discussion and announcement (it was quite a surprise for QA). It is still (barely) time to flip the default back, to what it always was. But there's no way enough time to _start_ the discussion now. It would consume weeks and by that time Beta should be out. I brought this up just over two months ago on both the anaconda and test lists and there was not all that much discussion then. So I don't see why it's such a big deal now. https://www.redhat.com/archives/anaconda-devel-list/2012-August/msg00116.html From an autopartition point of view, putting in code that's just going to be removed again come btrfs time doesn't make sense me. The autopartitioning for btrfs obviates lvm and md raid (except where md is needed to support a prior full disk IMSM RAID setup). I'm not convinced it makes sense to wedge LVM for autopartitioning when it's not needed in the next release. One release without it is not such a big deal, really. I think there are some LVM haters in the community who finally saw a chance to cleanse Fedora of this evil, and now will be very angry if someone wants to revert it. They might be wrong, they might be right. But I don't think this is the discussion we want to have now. That discussion should target Fedora 19. Now we should keep the defaults from previous Fedora versions. I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 19:23 -0600, Chris Murphy wrote: On Oct 25, 2012, at 4:32 PM, Kamil Paral kpa...@redhat.com wrote: The default was flipped to raw partitions in early builds of F18 Anaconda, and that was unfortunate, because it lacked a proper discussion and announcement (it was quite a surprise for QA). It is still (barely) time to flip the default back, to what it always was. But there's no way enough time to _start_ the discussion now. It would consume weeks and by that time Beta should be out. I brought this up just over two months ago on both the anaconda and test lists and there was not all that much discussion then. So I don't see why it's such a big deal now. https://www.redhat.com/archives/anaconda-devel-list/2012-August/msg00116.html From an autopartition point of view, putting in code that's just going to be removed again come btrfs time doesn't make sense me. The autopartitioning for btrfs obviates lvm and md raid (except where md is needed to support a prior full disk IMSM RAID setup). I'm not convinced it makes sense to wedge LVM for autopartitioning when it's not needed in the next release. One release without it is not such a big deal, really. Nothing gets 'wedged in' anywhere, there is no code to 'put in' (nor will any of the code that exists get 'removed' even when we default to btrfs, I don't think). I already posted the patch: it's two lines. All the code for LVM autopart already exists and is the same code that has existed for years. The patch simply changes the way the autopart code is called from 'please don't use LVM' to 'please use LVM'. It is two lines. http://fpaste.org/w1vE/ I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. The tricky thing is that the argument kind of cuts both ways: the thing that's the big change here was changing from LVM-by-default to raw-ext4-by-default, and that should have been clearly publicised and discussed. The fact that there are people just now finding out that it happened and being unhappy about it rather indicates that the planned change _wasn't_ properly communicated. I don't really see any great options here, unfortunately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Oct 25, 2012, at 7:38 PM, Adam Williamson awill...@redhat.com wrote: Nothing gets 'wedged in' anywhere, there is no code to 'put in' (nor will any of the code that exists get 'removed' even when we default to btrfs, I don't think). I already posted the patch: it's two lines. All the code for LVM autopart already exists and is the same code that has existed for years. The patch simply changes the way the autopart code is called from 'please don't use LVM' to 'please use LVM'. It is two lines. http://fpaste.org/w1vE/ So the loose proposal here is to add this patch just for F18, and then undo it for F19? I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. The tricky thing is that the argument kind of cuts both ways: the thing that's the big change here was changing from LVM-by-default to raw-ext4-by-default, and that should have been clearly publicised and discussed. The fact that there are people just now finding out that it happened and being unhappy about it rather indicates that the planned change _wasn't_ properly communicated. There are other explanations than it being improperly communicated. We've had this same autopartitioning behavior for how many weeks? It is only affecting autopartitioning. I'm not realy clear what the downside even is, which is why I didn't have a fit over this two months ago. It's just a default for most people who either don't care, or don't understand the alternatives. Everyone else will use Manual Partitioning. I think the public beta will make this more clear, however, how many people really expect LVM autopartitioning. But I really don't think it's that big of a deal. It's a default. Don't like the default? Change it. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 20:14 -0600, Chris Murphy wrote: On Oct 25, 2012, at 7:38 PM, Adam Williamson awill...@redhat.com wrote: Nothing gets 'wedged in' anywhere, there is no code to 'put in' (nor will any of the code that exists get 'removed' even when we default to btrfs, I don't think). I already posted the patch: it's two lines. All the code for LVM autopart already exists and is the same code that has existed for years. The patch simply changes the way the autopart code is called from 'please don't use LVM' to 'please use LVM'. It is two lines. http://fpaste.org/w1vE/ So the loose proposal here is to add this patch just for F18, and then undo it for F19? The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default _now_, for one release (or possibly two), only to change it again shortly. I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. The tricky thing is that the argument kind of cuts both ways: the thing that's the big change here was changing from LVM-by-default to raw-ext4-by-default, and that should have been clearly publicised and discussed. The fact that there are people just now finding out that it happened and being unhappy about it rather indicates that the planned change _wasn't_ properly communicated. There are other explanations than it being improperly communicated. We've had this same autopartitioning behavior for how many weeks? It is only affecting autopartitioning. I'm not realy clear what the downside even is, which is why I didn't have a fit over this two months ago. It's just a default for most people who either don't care, or don't understand the alternatives. Everyone else will use Manual Partitioning. I think the public beta will make this more clear, however, how many people really expect LVM autopartitioning. But I really don't think it's that big of a deal. It's a default. Don't like the default? Change it. You're probably right if everyone takes a step back that it's not a _huge_ deal. It's slightly more difficult to change in newUI than it was in oldUI, as things stand: there's no drop-down/checkbox 'change the autopart algorithm' thing as there was in oldUI. You have to go into custom partitioning and either create an LVM-based layout from scratch, or hit 'create partitions automatically' and then change their type to LVM. But it's not a huge problem, no, and you'd think people who are LVM-savvy could handle it. If anything the debate is about the experience of those who don't really care at install time, but theoretically might later. Some worry about the 'difficulty' of understanding LVM for these non-caring users. Some suggest that maybe these non-caring users might hit a problem they can solve with the help of LVM, like filling up their / partitions. As always with Fedora debates it's a bit fuzzy because we don't have any good data. Plus ca change. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
