default file system, was: Comparison to Workstation Technical Specification

Dennis Gilmore dennis at ausil.us
Thu Feb 27 23:25:50 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 27 Feb 2014 16:03:06 -0500
Josh Boyer <jwboyer at fedoraproject.org> wrote:

> On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore <dennis at ausil.us>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thu, 27 Feb 2014 15:01:47 -0500
> > Matthew Miller <mattdm at 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-----


More information about the cloud mailing list