11:18 p.m.
On Feb 26, 2014, at 5:33 PM, Josef Bacik <josef(a)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
6:43 a.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
-----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(a)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(a)lists.fedoraproject.org
(making this the last cross-posted message in the thread).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMPMwkACgkQeiVVYja6o6OMDgCgpflR85zdgCFaGKPRp1z8WUnI
ZbAAoJT2KdC5Pzx6XTo7Ju+x+PO+g13X
=q//v
-----END PGP SIGNATURE-----
6:53 a.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
On 27 February 2014 13:43, Stephen Gallagher <sgallagh(a)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
2:01 p.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
2:59 p.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500
Matthew Miller <mattdm(a)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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTD6dDAAoJEH7ltONmPFDR2vIP/1UwuBljIlxWvuVOYMp1DkSm
zj1svbpIDQAsrOyTjVBr/wpGzTN87YdnFjszf86YUaWq75TJqHMC0vEw/zO22ito
vK4dkbH0do0FzDlJi0YpQT2tgWh7EY89yDCSrU+NIml0MkFbAeLJMGzpIhCX3eIt
FMCi34n6dXNo1XIWSFFC4EINN7NV9ST/NYnOS7VPM49DERiiBDS39HZjNuPuvH0S
XjLpwObuLQ8i/kH++U8sBOSticImAgHZ1GWtHjrJdlT3X9SYrgUqcTNhfLJ95iAr
bSjm3aCmcZEVtAs8UrVx55wjQzyFaX4Mp3lzrwAVz91NUovY4tj/NVd/I0c1VnQ5
Ra0GgIKAWKukm++f2UM/uxIUgWCC5irC5fCi0vJwa9ZCd+GCoRJ4rhxLAEG0cIkd
O0SWkaYDV/oCQmFpYL3hh3X7+dWTTZ7vAFdqxSB88K0NAfCd/C+2Qzg7YMC5UhZb
hiY1Zmwx7Unt5jM0FHefuHgQmTuhq9G9VGm+zobLv0BAZTO/FqxUTGxfujg3AtTT
f+Vb6h+LuRaNWx/vEdnpeD/21/yWAhl6Sn9XEyB0/Cwc8MTGRZhcKAtaOAq73/sd
WcauN2uUO8vGp9T+xwnU47g3zAxbfIMd3fsr5ibMIh3GzX3A+soVy5prg2MDX7FT
0tWptq1/zM+i2AMjRwRQ
=KpHb
-----END PGP SIGNATURE-----
3:03 p.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 27 Feb 2014 15:01:47 -0500
Matthew Miller <mattdm(a)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
3:06 p.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
5:25 p.m.
New subject: default file system, was: Comparison to Workstation Technical Specification
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 27 Feb 2014 16:03:06 -0500
Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore
<dennis(a)ausil.us>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 27 Feb 2014 15:01:47 -0500
> Matthew Miller <mattdm(a)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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTD8mDAAoJEH7ltONmPFDR/8wQALqc78H5OeJIvzKIJbTFaTR3
YKsVoKRtz/bZgBN2J+UU2neqrDtj9Zrx6BP57M34RhnDInFk4Ja7EFgb3OjadxIk
U+ezFqVyy8w0oumGT1/DCgAemGU3XgbL57RIrymi7meWm8/lH9N+jKOH+zidqmLp
skaO3q/Fr0Y69GxyZYPzti6K3TbylBKPR7uvWSKP3relUylHNIKH1dmwIQvnk61O
LySTLaqXIdHsjFl4QblRTdvnL+kia5XQ1RykgcBenWrixouG+oi/ys83QvCkzT0G
EIOrcp8T///YJsvYQt1UQNavSIEbTw2oC5lQbf1jfQeY1YKW6qGruE4yTHFusZ44
RmSFXkJcbchc7eNhO05/uW90Dd0K9Tedr/1tXUnjr6T6yLkqwKOEDm1/yL66yGKN
fRnGG2bZOLydjU/n04cmG+ELYaQ6jFL6qLeeZcwEvFQ7mCmbq+GHiqsOMeDCROu+
ipeGHo7amZ6E/1YzeR2gioqOEZnrR3hJzgG9+iIMA7zsN7V9tlYqcbYzbDBs7+r+
y12XHFe3SSVuI1374uPKoLr8s15ysCKcUlqVOiU3sh3yepFBMep9v8yJXsNEvN8N
UqaI24HM0F08r+vWaW52T/G1XB2iZewOQEXohpjhlr3vBK+eDK4+Gxk7aiqhIURl
mN4ZfEkfxd29Ac5uobjm
=Uqxb
-----END PGP SIGNATURE-----
3704
days inactive
3704
days old
server@lists.fedoraproject.org
7 comments
6 participants
participants (6)
-
Chris Murphy -
Dennis Gilmore -
Josh Boyer -
Matthew Miller -
Rui Tiago Cação Matos -
Stephen Gallagher