Re: file systems
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
Reply to: