default file system, was: Comparison to Workstation Technical Specification

Kevin Fenzi kevin at scrye.com
Thu Feb 27 04:41:33 UTC 2014


On Wed, 26 Feb 2014 21:13:58 -0700
Chris Murphy <lists at colorremedies.com> wrote:

> 
> On Feb 26, 2014, at 1:54 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> 
> > Another aspect of xfs we may want to investigate and get feedback
> > from filesystem folks is how well xfs works on 32bit these days. 
> > 
> > RHEL7 doesn't have a 32bit version in their beta, so they only need
> > to support 64bit xfs. Does the fact that we expect to have 32bit
> > workstation and/or server weigh into this decision any?
> 
> I think the only limit is 16TB max file system, so off hand I'd say
> no. But this also applies to ext4.
> 
> I just tested with 3.13.4-200.fc20.i686+PAE.
> 
> XFS (sdc): file system too large to be mounted on this system.
> EXT4-fs (sdc): filesystem too large to mount safely on this system.
> 
> The same 32-bit kernel mounts a 20TB Btrfs volume with no complaints,
> so I don't know its limit.
> 
> http://paste.fedoraproject.org/80784/93470280/
> 
> XFS mounts with inode64 by default, same as x86_64. So that's good.

I wasn't referring to filesystem size limits... there was some issue
with Xfs and linux kernel stacks on 32bit linux causing crashes and
data loss.

I don't know if this has been fixed, no longer applies or just has been
ignored by only using it on 64bit machines, but before we go making it
a default and shipping it on 32bit, we should ask around about it. ;)

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/e611616a/attachment.sig>


More information about the server mailing list