7:08 a.m.
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.
7:28 a.m.
On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen <mclasen(a)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
7:05 p.m.
On Thu, Feb 27, 2014 at 8:28 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen
<mclasen(a)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
7:21 p.m.
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?
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
7:34 p.m.
On Fri, Feb 28, 2014 at 8:21 PM, Matthew Miller
<mattdm(a)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
7:35 a.m.
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(a)fedoraproject.org>
8:18 a.m.
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(a)fedoraproject.org>
To: "Discussions about development for the Fedora desktop"
<desktop(a)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(a)fedoraproject.org>
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
8:57 a.m.
On Mon, Mar 3, 2014 at 9:18 AM, Christian Schaller <cschalle(a)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
9:05 a.m.
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
9:08 a.m.
On Mon, Mar 3, 2014 at 10:05 AM, Michael Catanzaro <mcatanzaro(a)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
8:52 a.m.
On Mon, Mar 3, 2014 at 8:35 AM, Matthew Miller <mattdm(a)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
1:56 p.m.
On Feb 28, 2014, at 6:21 PM, Matthew Miller <mattdm(a)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
1:23 p.m.
On Sat, 2014-03-01 at 12:56 -0700, Chris Murphy wrote:
On Feb 28, 2014, at 6:21 PM, Matthew Miller
<mattdm(a)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. :(
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:21 p.m.
On Mar 2, 2014, at 12:23 PM, Adam Williamson <awilliam(a)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(a)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
8:22 p.m.
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
8:31 p.m.
On Fri, Feb 28, 2014 at 9:22 PM, Rahul Sundaram <metherid(a)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
8:29 a.m.
-----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(a)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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMUkeEACgkQeiVVYja6o6NGMwCdGHeb9B9eHtTAHZsAkt53EMVb
q4oAoKRJllAxdw5hxjw4p0/vdEJ6mPBT
=hpjh
-----END PGP SIGNATURE-----
2:48 a.m.
On Sat, Mar 1, 2014 at 2:05 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Thu, Feb 27, 2014 at 8:28 AM, Josh Boyer
<jwboyer(a)fedoraproject.org> wrote:
> On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen <mclasen(a)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.
12:15 p.m.
On Sat 01 Mar 2014 12:48:34 AM PST, drago01 wrote:
On Sat, Mar 1, 2014 at 2:05 AM, Josh Boyer
<jwboyer(a)fedoraproject.org> wrote:
> On Thu, Feb 27, 2014 at 8:28 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>> On Thu, Feb 27, 2014 at 8:08 AM, Matthias Clasen <mclasen(a)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(a)fedoraproject.org
W: http://www.coolest-storm.net
9:13 a.m.
Luya Tshimbalanga (luya(a)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
10:33 a.m.
On Mon, 2014-03-03 at 10:13 -0500, Bill Nottingham wrote:
Luya Tshimbalanga (luya(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:02 a.m.
On Mon, 03.03.14 10:13, Bill Nottingham (notting(a)redhat.com) wrote:
Luya Tshimbalanga (luya(a)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, Red Hat
11:08 a.m.
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.
11:41 a.m.
On Mar 3, 2014, at 10:08 AM, Michael Cronenworth <mike(a)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
2:18 p.m.
On Mon, 2014-03-03 at 10:41 -0700, Chris Murphy wrote:
On Mar 3, 2014, at 10:08 AM, Michael Cronenworth
<mike(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:25 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:43 p.m.
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson <awilliam(a)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.
2:12 p.m.
On Sun, 2014-03-02 at 20:43 +0100, drago01 wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson
<awilliam(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:16 p.m.
On Sun, Mar 2, 2014 at 9:12 PM, Adam Williamson <awilliam(a)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(a)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").
5:42 p.m.
On Mar 2, 2014, at 1:16 PM, drago01 <drago01(a)gmail.com> wrote:
On Sun, Mar 2, 2014 at 9:12 PM, Adam Williamson
<awilliam(a)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(a)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
5:37 p.m.
On Mar 2, 2014, at 12:43 PM, drago01 <drago01(a)gmail.com> wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson
<awilliam(a)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
6:27 p.m.
On Sun, Mar 2, 2014 at 6:37 PM, Chris Murphy <lists(a)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
7 p.m.
On Mar 2, 2014, at 5:27 PM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Sun, Mar 2, 2014 at 6:37 PM, Chris Murphy
<lists(a)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
3701
days inactive
3705
days old
desktop@lists.fedoraproject.org
32 comments
14 participants
participants (14)
-
Adam Williamson -
Bill Nottingham -
Chris Murphy -
Christian Schaller -
drago01 -
Josh Boyer -
Lennart Poettering -
Luya Tshimbalanga -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Michael Cronenworth -
Rahul Sundaram -
Stephen Gallagher