On Thu, Feb 27, 2014 at 01:12:28AM -0700, Chris Murphy wrote: > On Feb 27, 2014, at 12:21 AM, Dave Chinner <david@xxxxxxxxxxxxx> > wrote: > > On Wed, Feb 26, 2014 at 10:37:59PM -0700, Chris Murphy wrote: > >> Hi, > >> > >> Fedora is considering XFS as their default file system. They > >> support three primary architectures: x86_64, i686, and armv7hl. > >> Do XFS devs have any reservations about XFS as a default file > >> system on either i686, or arm? > > > > i686 is regularly tested on upstream dev kernels. ARM is less > > tested as it's not the primary development platform for anyone - > > we tend to rely on community feedback for arm because the > > hardware is so wide and varied and there are some crackpot CPU > > cache architectures out there in ARM land that we simply can't > > test against…. > > OK good, I'll post the URL for your response to the relevant > Fedora lists. > > > > >> So far the only thing I've run into with kernel > >> 3.13.4-200.fc20.i686+PAE will not mount an XFS volume larger > >> than 16TB. > > > > That's not an XFS limit - that's a limit of the block device > > caused by the page cache address space being limited to 16TB. > > Techinically the XFS kernel doesn't have such a limit because it > > doesn't use the block device address space to index or cache > > metadata, but that doesn't help anyone if the userspace tools > > don't work on anything larger than a 16TB block device. > > Are the kernel messages regarding corruption slightly misleading? Yes. > i.e. the file system on-disk isn't corrupt, but the kernel's view > of it is distorted because of the page cache limit? Someone has a > weird drunken bet, because I can't think of a good reason why, and > they mount a valued 16+TB XFS volume from a 64-bit system on a > 32-bit system, they don't really have to run xfs_repair once > putting it back on the 64-bit system, do they? No, it's not corrupt. The verifier on the superblock has been a bit heavy-handed in considering bad configurations such as this as corruption. i.e. it's out of range, it must be corrupt! However, the failure we are returning is not corruption, but EFBIG, and hence this patch just went into 3.14-rc3: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=5ef11eb0700f806c4671ba33e5befa784a2f70ef to fix that classification problem - the superblock verifier should now only be noisy if actual corruption is detected. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
