I'm CC'ing back to debian-user as I believe others may find this information useful.
Ron Johnson put forth on 4/25/2011 11:15 PM: > Stan: "Thus moving to EXT4 gains you nothing on a 32 bit machine," > > Ron: It gives me the ability to do a fsck! Only on rare occasions should one _need_ to run xfs_check or xfs_repair. > Stan: "This is not a 32 bit system limitation per se, as you initially > claimed" > > Ron: xfs_check barfs on a 32-bit system with scads of RAM and a PAE kernel. > fsck.ext4 does not. This is likely because your xfs_check binary isn't built to use PAE memory. I haven't researched it, but I'm making an educated guess that the 32bit Debian xfsprogs binaries weren't built with PAE support. Building your own xfsprogs with PAE support may allow your xfs_check to access most of your RAM thus eliminating this problem, though I'm no expert WRT PAE userland. You're better off using 'xfs_repair -n' if it doesn't suffer the out of memory error. > Stan: "but a memory size limitation, as the error clearly states" > > Ron: No kidding, Sherlock. > > Stan: "This is a well known issue with xfs_check BTW" > > Ron: So I find after I create huge FSs on a 32-bit system. There are some less than well documented issues WRT running 32 bit Linux/XFS. Background: XFS was born on IRIX on 64 bit MIPS CPUS and lived exclusively on this platform for 6-7 years. When SGI ported XFS from IRIX to Linux they added support for 32 bit kernels because they _had_ to, not because they wanted to. A requirement of getting any code into Linux mainline is compatibility with both 32 bit and 64 bit kernels. 32 bit Linux XFS was seen as a necessary evil. Their only goal was getting 64 bit XFS running on their new Altix supercomputers containing Intel Itanium CPUs, and getting XFS into mainline so they could use off the shelf distros, such as SUSE and Redhat, instead of continuing to maintain their own "Propack" patch set for Linux. > Stan: "Using 'xfs_repair -n' will give you essentially the same results as > xfs_check" > > Ron: Then why are there two different code paths? (Yes, I know that you > can't answer.) Actually, yes, I can, well, the docs can, to some degree: http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/ch11s02.html http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/ch11s03.html > Ron: Anyway, boot scripts do fsck, so that work-around is *effectively* > irrelevant. On the contrary. xfs_check has _never_ been run via boot scripts. XFS is a journaling filesystem, one of the first available on a production system. The primary reason filesystem journals were invented was to eliminate the traditional long running fsck at boot. Here's the fsck.xfs boot script from a Squeeze box. AFAIK this script hasn't functionally changed since XFS was added to Linux. It's always done absolutely nothing. It exists strictly for compatibility. ~$ cat /sbin/fsck.xfs #!/bin/sh -f # # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. # AUTO=false while getopts ":aApy" c do case $c in a|A|p|y) AUTO=true;; esac done eval DEV=\${$#} if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi if $AUTO; then echo "$0: XFS file system." else echo "If you wish to check the consistency of an XFS filesystem or" echo "repair a damaged filesystem, see xfs_check(8) and xfs_repair(8)." fi exit 0 > "Since most x86 chips shipped in the past 6 years support x86-64, you're > better off using a full 64 bit distro and a machine with 8GB or more RAM." > > Blame Adobe for not making a decent 64-bit Flash plugin. (No, I do > *not* use Flash primarily for watch YouTube. The reason why you use a 32 bit system is irrelevant to me. Though up to this point I assumed we were discussing a server. Regardless, use 'xfs_repair -n" instead of xfs_check and you should be good to go, again, assuming 'xfs_repair -n' doesn't run out of memory on your machine. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db67726.1030...@hardwarefreak.com