I've updated the spec to say
The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin.
Lets move on to more important topics.
On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen mclasen@redhat.com wrote:
I've updated the spec to say
The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin.
Great, thanks. I'm sure we'll revisit if people want to keep things similar with Server, so having rationale on being different from them would be good if we go that route.
Lets move on to more important topics.
Agreed for now. Thanks to everyone that chimed in on the discussion. While the results might not be exactly what we wanted, it was a good discussion overall.
josh
On Thu, Feb 27, 2014 at 8:28 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen mclasen@redhat.com wrote:
I've updated the spec to say
The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin.
Great, thanks. I'm sure we'll revisit if people want to keep things similar with Server, so having rationale on being different from them would be good if we go that route.
OK, so the QA people would really like to limit the number of default filesystems across the products if there is no good reason to differentiate. With that in mind, the current desktop setup "install to hard drive" options for the live image defaults to ext4 on LVM. Does anyone have major objections to changing Workstation to default to XFS on LVM for the install to hard drive path?
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
Thoughts?
josh
On Fri, Feb 28, 2014 at 08:05:34PM -0500, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I'd really like to have the discussion about whether btrfs is still a medium-term goal. I agree that XFS and ext4 seem basically the same, and if btrfs is still where we really want to go, I kind of think we should avoid the churn of swapping in one similar thing for another. (Since RHEL7 has already forked, that ship has sailed.) We talked about having btrfs/xfs filesystem talks at Flock -- is waiting until then too late to decide?
On Fri, Feb 28, 2014 at 8:21 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Feb 28, 2014 at 08:05:34PM -0500, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I'd really like to have the discussion about whether btrfs is still a medium-term goal. I agree that XFS and ext4 seem basically the same, and if btrfs is still where we really want to go, I kind of think we should avoid the churn of swapping in one similar thing for another. (Since RHEL7 has already forked, that ship has sailed.) We talked about having btrfs/xfs filesystem talks at Flock -- is waiting until then too late to decide?
Are we really going to repeat the whole conversation we already had around this earlier in the week?
To summarize where things stand:
- Btrfs is where Workstation would like to be for ease of use and feature reasons - Btrfs is not ready, according to everyone that actually works on the kernel including one of the btrfs maintainers. Waiting until Flock is not going to change that. - The timeframe for btrfs as a default is 6mo to a year, but it's been in that timeframe before. Really it boils down to how much upstream attention it gets, who else is using it, etc. It's hard to see the future. Exactly what needs to improve, be fixed, etc _can_ be talked about at Flock and I'm still hoping to get that to happen. - dm-thinp might be an option for some of the features, but nobody in Workstation has looked hard at that. - QA and Server would really like commonality across as many of the products as possible. - From an FS standpoint, ext4 and XFS are mostly comparable in the Workstation case. - One can convert ext4 to btrfs but several people would likely curl into a ball and weep uncontrollably if that option was offered in the installer. It is not a sane option.
I get the churn argument, but I'm not sure how much it matters. The defaults are only for new installs, and I seriously doubt the lifecycle of the first Workstation product is going to be significantly longer than an existing Fedora release. Early adopters that are keen on future features can choose the custom method and go with btrfs now. The rest that just want something to work will have something that works and can backup/reinstall if a significant amount of new function is created around a future Workstation btrfs release.
So. I'd like to crap or get off the pot now. This is supposedly due Monday, but every time someone insists I revisit it, it's going to take that much longer. Do you have something new we've missed?
josh
On Fri, Feb 28, 2014 at 08:34:26PM -0500, Josh Boyer wrote:
btrfs is still where we really want to go, I kind of think we should avoid the churn of swapping in one similar thing for another. (Since RHEL7 has already forked, that ship has sailed.) We talked about having btrfs/xfs filesystem talks at Flock -- is waiting until then too late to decide?
Are we really going to repeat the whole conversation we already had around this earlier in the week?
[...]
So. I'd like to crap or get off the pot now. This is supposedly due Monday, but every time someone insists I revisit it, it's going to take that much longer. Do you have something new we've missed?
I did read all of that, and sorry if I'm being obtuse. I think it really makes a difference if we still intend for btrfs to be the default in the medium term (not just in hopeful thinking). If that is the case for workstation but server still wants XFS even then, there doesn't seem to be any point in bothering with consistency now since it won't be consistent in a little bit anyway. On the other hand, if server does want to go with btrfs and relatively soon, and again if consistency is important, I'd like to push back on *server's* decision.
Or in matrix form:
Consistency Consistency Valuable Not Important +---------------------------------------------+ Btrfs | All products should | Workstation should | actually | stay with ext4 | probably stay ext4; | ready soon | | cloud definitely will | | | | +---------------------+-----------------------+ | All products should | Whatever | Btrfs more | switch to XFS | | than 3* | | | years out | | | +---------------------------------------------
* where "3" is an arbitrary number higher than 2; exact value tbd
I agree with Matthew here that if we are going with btrfs for the medium/long term, then that has an impact on our decision for default filesystem in the short term. To me it seems like switching to XFS for the workstation doesn't make sense if we still want to get onto btrfs at some point. It just means we will find ourselves with our users spread across one more filesystem medium/long term.
The harder question is to what degree we are able to trust in btrfs 'getting there' within a given timeframe. On the other hand if Suse ships it then we should at least be able to go to the limited feature version they use at some point.
Christian
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, March 3, 2014 2:35:09 PM Subject: Re: default filesystem
On Fri, Feb 28, 2014 at 08:34:26PM -0500, Josh Boyer wrote:
btrfs is still where we really want to go, I kind of think we should avoid the churn of swapping in one similar thing for another. (Since RHEL7 has already forked, that ship has sailed.) We talked about having btrfs/xfs filesystem talks at Flock -- is waiting until then too late to decide?
Are we really going to repeat the whole conversation we already had around this earlier in the week?
[...]
So. I'd like to crap or get off the pot now. This is supposedly due Monday, but every time someone insists I revisit it, it's going to take that much longer. Do you have something new we've missed?
I did read all of that, and sorry if I'm being obtuse. I think it really makes a difference if we still intend for btrfs to be the default in the medium term (not just in hopeful thinking). If that is the case for workstation but server still wants XFS even then, there doesn't seem to be any point in bothering with consistency now since it won't be consistent in a little bit anyway. On the other hand, if server does want to go with btrfs and relatively soon, and again if consistency is important, I'd like to push back on *server's* decision.
Or in matrix form:
Consistency Consistency Valuable Not Important +---------------------------------------------+
Btrfs | All products should | Workstation should | actually | stay with ext4 | probably stay ext4; | ready soon | | cloud definitely will | | | | +---------------------+-----------------------+ | All products should | Whatever | Btrfs more | switch to XFS | | than 3* | | | years out | | | +---------------------------------------------
- where "3" is an arbitrary number higher than 2; exact value tbd
-- Matthew Miller -- Fedora Project -- mattdm@fedoraproject.org -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Mon, Mar 3, 2014 at 9:18 AM, Christian Schaller cschalle@redhat.com wrote:
I agree with Matthew here that if we are going with btrfs for the medium/long term, then that has an impact on our decision for default filesystem in the short term. To me it seems like switching to XFS for the workstation doesn't make sense if we still want to get onto btrfs at some point. It just means we will find ourselves with our users spread across one more filesystem medium/long term.
Right. Workstation gets no benefit from switching to XFS other than it makes QA happier (for fairly valid reasons). If Server wasn't switching, this wouldn't even be a conversation. I think we'll likely just have to stick with ext4 and pitch in on the UI and QA fronts if that somehow leads to major burden. I expect Server will need to do the same for the XFS route as well.
The harder question is to what degree we are able to trust in btrfs 'getting there' within a given timeframe. On the other hand if Suse ships it then we should at least be able to go to the limited feature version they use at some point.
I think it's something we (the FS and Fedora kernel people) will really have to keep an eye on. This _are_ improving, so it's a matter of timeframes really. I'm still hoping to get a talk on it at Flock, and then reassess for the next Workstation release. In the meantime, I guess I'll be booting more machines with btrfs to play along.
josh
On Mon, 2014-03-03 at 09:18 -0500, Christian Schaller wrote:
On the other hand if Suse ships it then we should at least be able to go to the limited feature version they use at some point.
I believe SUSE Linux Enterprise 12 (to be released this year) will default to btrfs, unless their plans have changed. This is confirmed at the bottom of [1]; for the rationale, see [2].
[1] http://lists.opensuse.org/opensuse-factory/2013-09/msg00115.html [2] http://lists.opensuse.org/opensuse-factory/2013-09/msg00096.html
On Mon, Mar 3, 2014 at 10:05 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2014-03-03 at 09:18 -0500, Christian Schaller wrote:
On the other hand if Suse ships it then we should at least be able to go to the limited feature version they use at some point.
I believe SUSE Linux Enterprise 12 (to be released this year) will default to btrfs, unless their plans have changed. This is confirmed at
They might have changed. It was supposed to be default in OpenSUSE 13.1, but isn't. It _is_ offered in reduced feature mode, as has been discussed a few times on the list already.
We'll have to wait an see what OpenSUSE 13.2/SLES 12 do I guess, but we aren't going to switch simply because they do. Our situations are somewhat different.
josh
On Mon, Mar 3, 2014 at 8:35 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Feb 28, 2014 at 08:34:26PM -0500, Josh Boyer wrote:
btrfs is still where we really want to go, I kind of think we should avoid the churn of swapping in one similar thing for another. (Since RHEL7 has already forked, that ship has sailed.) We talked about having btrfs/xfs filesystem talks at Flock -- is waiting until then too late to decide?
Are we really going to repeat the whole conversation we already had around this earlier in the week?
[...]
So. I'd like to crap or get off the pot now. This is supposedly due Monday, but every time someone insists I revisit it, it's going to take that much longer. Do you have something new we've missed?
I did read all of that, and sorry if I'm being obtuse. I think it really makes a difference if we still intend for btrfs to be the default in the medium term (not just in hopeful thinking). If that is the case for workstation but server still wants XFS even then, there doesn't seem to be any point in bothering with consistency now since it won't be consistent in a little bit anyway. On the other hand, if server does want to go with btrfs and relatively soon, and again if consistency is important, I'd like to push back on *server's* decision.
Thanks for the clarification.
josh
On Feb 28, 2014, at 6:21 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Feb 28, 2014 at 08:05:34PM -0500, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I'd really like to have the discussion about whether btrfs is still a medium-term goal.
I don't think a broader conversation on Btrfs is in scope for the Workstation tech spec. What I think is relevant right now, is whether there should still be a Btrfs guided partitioning option, which is what we currently have in Fedora 20 and older. Or if there shall only be the default.
It's curiously ostensible to say we'll use Btrfs when it's ready in maybe a year, but then drop it as an alternate easy install option. I also think it's appropriate to label it in the pop-up with "Preview" or "Work in Progress".
I propose for automatic/guided partitioning:
Server: Default=LVM with XFS Alternate = none
Workstation: Default= Standard Partitioning (ext4) Alternate = Btrfs – Preview
This of course assumes there's no Anaconda revolt due to the ensuing UI difference of Server having no Partition Scheme (or equivalent) drop down; and Workstation having one. A possible work around for that is giving both Server and Workstation a "Btrfs - Preview" option.
Chris Murphy
On Sat, 2014-03-01 at 12:56 -0700, Chris Murphy wrote:
On Feb 28, 2014, at 6:21 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Feb 28, 2014 at 08:05:34PM -0500, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I'd really like to have the discussion about whether btrfs is still a medium-term goal.
I don't think a broader conversation on Btrfs is in scope for the Workstation tech spec. What I think is relevant right now, is whether there should still be a Btrfs guided partitioning option, which is what we currently have in Fedora 20 and older. Or if there shall only be the default.
It's curiously ostensible to say we'll use Btrfs when it's ready in maybe a year, but then drop it as an alternate easy install option. I also think it's appropriate to label it in the pop-up with "Preview" or "Work in Progress".
I propose for automatic/guided partitioning:
Server: Default=LVM with XFS Alternate = none
Workstation: Default= Standard Partitioning (ext4) Alternate = Btrfs – Preview
So now we have three guided paths to test, which is barely an improvement on four? I thought we had previously agreed that we wanted to cut these down as far as possible. :(
On Mar 2, 2014, at 12:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2014-03-01 at 12:56 -0700, Chris Murphy wrote:
On Feb 28, 2014, at 6:21 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Feb 28, 2014 at 08:05:34PM -0500, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I'd really like to have the discussion about whether btrfs is still a medium-term goal.
I don't think a broader conversation on Btrfs is in scope for the Workstation tech spec. What I think is relevant right now, is whether there should still be a Btrfs guided partitioning option, which is what we currently have in Fedora 20 and older. Or if there shall only be the default.
It's curiously ostensible to say we'll use Btrfs when it's ready in maybe a year, but then drop it as an alternate easy install option. I also think it's appropriate to label it in the pop-up with "Preview" or "Work in Progress".
I propose for automatic/guided partitioning:
Server: Default=LVM with XFS Alternate = none
Workstation: Default= Standard Partitioning (ext4) Alternate = Btrfs – Preview
So now we have three guided paths to test, which is barely an improvement on four?
The above language isn't well qualified on my part, it's just an idea that the Workstation WG consider. I'm not married to the Btrfs alternate, and it's debatable whether it improves Btrfs test coverage anyway.
I thought we had previously agreed that we wanted to cut these down as far as possible. :(
You're right, we had. The "as far as possible" means Workstation and Server agree with each other on a default, with no alternate. And I still agree that's the best outcome.
Chris Murphy
Hi
On Fri, Feb 28, 2014 at 8:05 PM, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I would say, for consistency, Fedora needs to stick to Ext4 for now and switch to Btrfs when it is ready rather than go through a switch to XFS for no real gain. Why is the server team choosing to switch to XFS anyway?
Rahul
On Fri, Feb 28, 2014 at 9:22 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Feb 28, 2014 at 8:05 PM, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I would say, for consistency, Fedora needs to stick to Ext4 for now and switch to Btrfs when it is ready rather than go through a switch to XFS for
Yes, well. As I outlined, some want consistency between products. Some apparently want consistency with the past. Some want consistency in whatever way for test reasons. The only thing consistent about all of this is that everyone has a different definition of consistent.
no real gain. Why is the server team choosing to switch to XFS anyway?
I already explained the response I got in the email you replied to. Beyond that, I guess we wait for the Server group to provide rationale.
josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/28/2014 09:31 PM, Josh Boyer wrote:
On Fri, Feb 28, 2014 at 9:22 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Feb 28, 2014 at 8:05 PM, Josh Boyer wrote:
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
I would say, for consistency, Fedora needs to stick to Ext4 for now and switch to Btrfs when it is ready rather than go through a switch to XFS for
Yes, well. As I outlined, some want consistency between products. Some apparently want consistency with the past. Some want consistency in whatever way for test reasons. The only thing consistent about all of this is that everyone has a different definition of consistent.
no real gain. Why is the server team choosing to switch to XFS anyway?
I already explained the response I got in the email you replied to. Beyond that, I guess we wait for the Server group to provide rationale.
Reposting this to the desktop list:
Ric Wheeler (Red Hat's storage and filesystem lead) gave some details on why he recommends XFS for the *Server* use-case:
https://lists.fedoraproject.org/pipermail/devel/2014-March/196190.html https://lists.fedoraproject.org/pipermail/devel/2014-March/196193.html
I should note that he also recommends EXT4 for Workstation.
On Sat, Mar 1, 2014 at 2:05 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 8:28 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen mclasen@redhat.com wrote:
I've updated the spec to say
The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin.
Great, thanks. I'm sure we'll revisit if people want to keep things similar with Server, so having rationale on being different from them would be good if we go that route.
OK, so the QA people would really like to limit the number of default filesystems across the products if there is no good reason to differentiate. With that in mind, the current desktop setup "install to hard drive" options for the live image defaults to ext4 on LVM. Does anyone have major objections to changing Workstation to default to XFS on LVM for the install to hard drive path?
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
Thoughts?
Well I don't see any gain from moving to XFS. We will end up with a lot of people (those who upgrade) to be using ext4 anyway. As for the installation QA I don't think the file system itself is a major source of churn / bugs.
As for "on LVM" ... I am not convinced LVM adds any gains on workstation especially if the workstation is a laptop.
On Sat 01 Mar 2014 12:48:34 AM PST, drago01 wrote:
On Sat, Mar 1, 2014 at 2:05 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 8:28 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen mclasen@redhat.com wrote:
I've updated the spec to say
The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin.
Great, thanks. I'm sure we'll revisit if people want to keep things similar with Server, so having rationale on being different from them would be good if we go that route.
OK, so the QA people would really like to limit the number of default filesystems across the products if there is no good reason to differentiate. With that in mind, the current desktop setup "install to hard drive" options for the live image defaults to ext4 on LVM. Does anyone have major objections to changing Workstation to default to XFS on LVM for the install to hard drive path?
Others have pointed out that the RHEL7 client uses XFS already. I'm of the opinion that ext4 vs. XFS is pretty comparable for most cases, so I have no strong objections either way.
Thoughts?
Well I don't see any gain from moving to XFS. We will end up with a lot of people (those who upgrade) to be using ext4 anyway. As for the installation QA I don't think the file system itself is a major source of churn / bugs.
As for "on LVM" ... I am not convinced LVM adds any gains on workstation especially if the workstation is a laptop.
Is it possible for the installer to detect if the machine is either a laptop or a desktop? That was LWM could be disabled by default.
-- Luya Tshimbalanga Graphic & Web Designer E: luya@fedoraproject.org W: http://www.coolest-storm.net
Luya Tshimbalanga (luya@fedoraproject.org) said:
As for "on LVM" ... I am not convinced LVM adds any gains on workstation especially if the workstation is a laptop.
Is it possible for the installer to detect if the machine is either a laptop or a desktop? That was LWM could be disabled by default.
/sys/class/dmi/id/chassis_type
Of course, that value comes from the firmware. You want to trust firmware vendors?
Bill
On Mon, 2014-03-03 at 10:13 -0500, Bill Nottingham wrote:
Luya Tshimbalanga (luya@fedoraproject.org) said:
As for "on LVM" ... I am not convinced LVM adds any gains on workstation especially if the workstation is a laptop.
Is it possible for the installer to detect if the machine is either a laptop or a desktop? That was LWM could be disabled by default.
/sys/class/dmi/id/chassis_type
Of course, that value comes from the firmware. You want to trust firmware vendors?
And also, just please, no.
Chris' and my read on the discussion over the weekend is that WS is trending towards ext4-on-LVM by default. We can live with that, we're not going to make a stink. Two old-school FSes on LVM as our two defaults isn't the worst outcome in the world.
If both workstation and server are OK with having no alternatives on the guided path (alternatives all in custom partitioning), that still makes things rather better for testing (and I think development) than they were before.
On Mon, 03.03.14 10:13, Bill Nottingham (notting@redhat.com) wrote:
Luya Tshimbalanga (luya@fedoraproject.org) said:
As for "on LVM" ... I am not convinced LVM adds any gains on workstation especially if the workstation is a laptop.
Is it possible for the installer to detect if the machine is either a laptop or a desktop? That was LWM could be disabled by default.
/sys/class/dmi/id/chassis_type
Of course, that value comes from the firmware. You want to trust firmware vendors?
This tends to be a better source for information like this:
/sys/firmware/acpi/pm_profile
And since Windows cares for this bit it even tends to be reliable to some level.
hostnamed exposes a "Chassis" property on the bus (and hostnamectl will show you this), which looks for both of this files and allows users to override this file.
That said, it sounds like a horrible hack to make use of this for turning on/off LVM.
Quite frankly, I am pretty sure LVM has no place on non-servers, and should not be offered by the desktop installer.
Lennart
Lennart Poettering wrote:
Quite frankly, I am pretty sure LVM has no place on non-servers, and should not be offered by the desktop installer.
The server use-cases could be questioned as well. The ones presented so far have been specialized cases.
If you care about zero-down time or redundancy then you need RAID (hardware or MDADM).
Please, let LVM die in a fire.
On Mar 3, 2014, at 10:08 AM, Michael Cronenworth mike@cchtml.com wrote:
Lennart Poettering wrote:
Quite frankly, I am pretty sure LVM has no place on non-servers, and should not be offered by the desktop installer.
The server use-cases could be questioned as well. The ones presented so far have been specialized cases.
Sure. Plain ext4 would in fact boot a server just as well as it does cloud and in some sense is more reliable as ext4 is baked into the kernel, unlike XFS or LVM.
If you care about zero-down time or redundancy then you need RAID (hardware or MDADM).
This could be made easier. Manual Partitioning doesn't really help build this, you really have to know what you're doing.
On UEFI, it's semi-broken in that degraded booting isn't possible to configure within the installer's Manual Partitioning panel: it doesn't auto-create (or make it feasible to manually create) the mandatory EFI System partitions on every drive, we don't install the boot loader to each ESP, and we put the grub.cfg in the ESP which is the wrong place. Presumably hot-swap drives are a given, and degraded boots aren't a top priority but…
Chris Murphy
On Mon, 2014-03-03 at 10:41 -0700, Chris Murphy wrote:
On Mar 3, 2014, at 10:08 AM, Michael Cronenworth mike@cchtml.com wrote:
Lennart Poettering wrote:
Quite frankly, I am pretty sure LVM has no place on non-servers, and should not be offered by the desktop installer.
The server use-cases could be questioned as well. The ones presented so far have been specialized cases.
Sure. Plain ext4 would in fact boot a server just as well as it does cloud and in some sense is more reliable as ext4 is baked into the kernel, unlike XFS or LVM.
If you care about zero-down time or redundancy then you need RAID (hardware or MDADM).
This could be made easier. Manual Partitioning doesn't really help build this, you really have to know what you're doing.
On UEFI, it's semi-broken in that degraded booting isn't possible to configure within the installer's Manual Partitioning panel: it doesn't auto-create (or make it feasible to manually create) the mandatory EFI System partitions on every drive, we don't install the boot loader to each ESP, and we put the grub.cfg in the ESP which is the wrong place. Presumably hot-swap drives are a given, and degraded boots aren't a top priority but…
Focus, please - we don't need to bring every known partitioning topic into this conversation, we really don't.
On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
As for the installation QA I don't think the file system itself is a major source of churn / bugs.
The people who do the installation QA are the ones who are telling you differently...
As for desktop development, I don't think it's big deal to add back options like panel location and transparent terminals.
;)
It all sounds nice and easy when you're writing a tech spec, but when the rubber hits the road it never is. We've *already shipped a release with one of the drop-down 'guided' options entirely broken*. This is not a theoretical problem.
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
As for the installation QA I don't think the file system itself is a major source of churn / bugs.
The people who do the installation QA are the ones who are telling you differently...
Care to provide any details? I mean I different partitions setups / raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ? All that anaconda has to do is call mkfs.whatever and add the proper name to fstab ... unless the mkfs.whatever itself is broken there shouldn't be much difference.
On Sun, 2014-03-02 at 20:43 +0100, drago01 wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
As for the installation QA I don't think the file system itself is a major source of churn / bugs.
The people who do the installation QA are the ones who are telling you differently...
Care to provide any details? I mean I different partitions setups / raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ? All that anaconda has to do is call mkfs.whatever and add the proper name to fstab ... unless the mkfs.whatever itself is broken there shouldn't be much difference.
Sure, so we immediately have twice as many mkfs'es that could be broken. We also have to make sure the tools are available to the installer environment and the initramfs; that was what went wrong with LVM thinp in F21 - the tools were missing from the initramfs because dracut over-optimized. There's always one more darn thing.
Yes, difference between container/non-container and complex filesystems like btrfs is more significant, but any difference adds failure points.
On Sun, Mar 2, 2014 at 9:12 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2014-03-02 at 20:43 +0100, drago01 wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
As for the installation QA I don't think the file system itself is a major source of churn / bugs.
The people who do the installation QA are the ones who are telling you differently...
Care to provide any details? I mean I different partitions setups / raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ? All that anaconda has to do is call mkfs.whatever and add the proper name to fstab ... unless the mkfs.whatever itself is broken there shouldn't be much difference.
Sure, so we immediately have twice as many mkfs'es that could be broken. We also have to make sure the tools are available to the installer environment and the initramfs; that was what went wrong with LVM thinp in F21 - the tools were missing from the initramfs because dracut over-optimized. There's always one more darn thing.
Yes, difference between container/non-container and complex filesystems like btrfs is more significant, but any difference adds failure points.
OK ... (I said "not a major source of bugs" not "never has any issues").
On Mar 2, 2014, at 1:16 PM, drago01 drago01@gmail.com wrote:
On Sun, Mar 2, 2014 at 9:12 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2014-03-02 at 20:43 +0100, drago01 wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
As for the installation QA I don't think the file system itself is a major source of churn / bugs.
The people who do the installation QA are the ones who are telling you differently...
Care to provide any details? I mean I different partitions setups / raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ? All that anaconda has to do is call mkfs.whatever and add the proper name to fstab ... unless the mkfs.whatever itself is broken there shouldn't be much difference.
Sure, so we immediately have twice as many mkfs'es that could be broken. We also have to make sure the tools are available to the installer environment and the initramfs; that was what went wrong with LVM thinp in F21 - the tools were missing from the initramfs because dracut over-optimized. There's always one more darn thing.
Yes, difference between container/non-container and complex filesystems like btrfs is more significant, but any difference adds failure points.
OK ... (I said "not a major source of bugs" not "never has any issues").
I don't see the distinction. LVM thinp blows up, it's a major bug if the user can't boot because not booting after install is typically a blocker bug, which is a major sort of bug. Grubby can't update grub.cfg because Btrfs subvolumes confuse it? It's a major bug, we compelled a code change to disallow /boot on Btrfs subvolumes because the grubby failure is silent with Gnome initiated updates and means updated kernels aren't ever used for booting - so it's potentially a security risk.
Chris Murphy
On Mar 2, 2014, at 12:43 PM, drago01 drago01@gmail.com wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
As for the installation QA I don't think the file system itself is a major source of churn / bugs.
The people who do the installation QA are the ones who are telling you differently...
Care to provide any details? I mean I different partitions setups / raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ? All that anaconda has to do is call mkfs.whatever and add the proper name to fstab ... unless the mkfs.whatever itself is broken there shouldn't be much difference.
We are being a bit loose with terminology considering LVM a file system. However, we had a lot of problems with LVM Thin Provisioning compared to regular LVM during Fedora 20 pre-release testing. It wasn't working at all prior to or after Alpha, up until the 11th hour before beta release. And then it blew up in our faces again after it passed all final release TC tests, it failed RC but it wasn't caught in time.
We also have a long standing grubby bug because it doesn't understand subvolumes. Because of some change in anaconda, grub2-mkconfig sometimes happens before the initramfs completes, so the grub.cfg doesn't have an initramfs entry. This gets fixed by grubby, except when /boot is on Btrfs, resulting in a kernel panic on boot. So now we disallow in Fedora 20 /boot on Btrfs subvolumes even in Manual Partitioning where it was previously permitted.
XFS doesn't support shrink. Do we have a bug somewhere in the installer that makes the user think it is? Does the installer try to shrink it? Or a bug when trying to grow it? Doubtful. But possible.
Arguably, we ought to be considering dumping ext2 and ext3 as fs options. The ext devs will freely admit that ext2 and ext3 aren't getting backports from the rather active ext4 work that's on-going, with any sort of consistency. So why should we be supporting them?
Chris Murphy
On Sun, Mar 2, 2014 at 6:37 PM, Chris Murphy lists@colorremedies.com wrote:
Arguably, we ought to be considering dumping ext2 and ext3 as fs options. The ext devs will freely admit that ext2 and ext3 aren't getting backports from the rather active ext4 work that's on-going, with any sort of consistency. So why should we be supporting them?
Depending on how you look at it, we aren't. We use the ext4 driver to mount ext2/3 filesystems on all recent releases.
config-generic:# CONFIG_EXT2_FS is not set config-generic:# CONFIG_EXT3_FS is not set config-generic:CONFIG_EXT4_FS=y config-generic:CONFIG_EXT4_USE_FOR_EXT23=y
josh
On Mar 2, 2014, at 5:27 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Sun, Mar 2, 2014 at 6:37 PM, Chris Murphy lists@colorremedies.com wrote:
Arguably, we ought to be considering dumping ext2 and ext3 as fs options. The ext devs will freely admit that ext2 and ext3 aren't getting backports from the rather active ext4 work that's on-going, with any sort of consistency. So why should we be supporting them?
Depending on how you look at it, we aren't. We use the ext4 driver to mount ext2/3 filesystems on all recent releases.
Sure. I meant in the installer. There's an ext2 option, yet no QA test case. And while there is a test case for ext3, it seems superfluous.
Chris Murphy
desktop@lists.fedoraproject.org