On Feb 26, 2014, at 5:33 PM, Josef Bacik josef@toxicpanda.com wrote:
Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default.
OK good, that's definitive. Thanks Josef.
So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4.
And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like… chickens with no heads, running.
Chris Murphy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/27/2014 12:18 AM, Chris Murphy wrote:
On Feb 26, 2014, at 5:33 PM, Josef Bacik <josef@toxicpanda.com mailto:josef@toxicpanda.com> wrote:
Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default.
OK good, that's definitive. Thanks Josef.
So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4.
And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like… chickens with no heads, running.
Speaking for myself, I have a slight preference on using XFS-on-LVM for the default filesystem in the Fedora Server, but if both of the other Products would prefer ext4-on-LVM, I suppose we could negotiate.
If we can arrange things so we only have a single installer with different install targets (at least for the net install), I'd consider the reduction in testing effort at least worthy of argument at being more valuable than the filesystem choice.
Question for the cloud folks:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Directed more broadly at all three products:
Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the "guided" mode. All is fair game in the "custom" mode.
Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread).
On 27 February 2014 13:43, Stephen Gallagher sgallagh@redhat.com wrote:
Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the "guided" mode. All is fair game in the "custom" mode.
What's the point of using LVM for the root filesystem?
Rui
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition
Dennis
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition
Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;).
josh
On Thu, Feb 27, 2014 at 04:03:06PM -0500, Josh Boyer wrote:
Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;).
Right, and as I understand it, there actually _is_ some level of support, and there was a GSoC project related to it a couple of years ago.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 16:03:06 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot.
Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So..... if by "/boot" you mean "the partition that /boot happens to be on, even if it is /", then I think we're good. Otherwise we will have to figure something else out.
u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition
Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;).
josh
the issue we have with u-boot is that we may have to change how we do some things. Some hardware we have relied on vendor provided u-boots. likely we would need to ship and update the u-boot the vendor provides to add functionality. the trimslice for instance has a u-boot that only boots from ext2 or ext3 and lacks ext4 support. the vendor has said that they will not be shipping any more u-boot updates, so in the case there we are going to have to ship our own update to support the work that has been going on upstream to unify features and boot support. I have been working upstream to get things moved over to using the available pxe/extlinux linux support.
longer term /boot on xfs may be possible, but it will take work
Dennis
server@lists.fedoraproject.org
-
Chris Murphy -
Dennis Gilmore -
Josh Boyer -
Matthew Miller -
Rui Tiago Cação Matos -
Stephen Gallagher