xfs
[Top] [All Lists]

Re: XFS weirdness <- GLibC, LFS and NFS ... oh my!

To: Jason Walker <unseen@xxxxxxxxx>, linux-xfs@xxxxxxxxxxx
Subject: Re: XFS weirdness <- GLibC, LFS and NFS ... oh my!
From: Bryan-TheBS-Smith <thebs@xxxxxxxxxxx>
Date: Wed, 28 Feb 2001 15:46:44 -0500
Organization: (Personal)
References: <Pine.LNX.4.10.10102281521550.10991-100000@surreal.localdomain>
Reply-to: thebs@xxxxxxxxxxx, b.j.smith@xxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
Jason Walker wrote:
> um..I just used a standard 2.4.x kernel.  2.4's VFS changed the
> addressing from 32bit to 64bit, I believe.  It's a 2.4 thing.

Yes, it's called LFS.  Kernel 2.2.x (or 2.0.x for that matter) had
no issues on 64-bit platforms (like Linux/Alpha).  As such, it's not
an VFS-specific issue.

Again, LFS is the reference POSIX implementation for 32-bit POSIX
architectures to overcome the integer limitations of 32-bit
processors, namely the 2GB (2^31, 32-bit signed integer)
limitation.  OSes that adopt LFS address the 32-bit limitations at
both the kernel and C Libraries.  On 64-bit POSIX systems (like
Linux/Alpha), both the kernel and C libraries are already 64-bit and
do not have such limitations.

In the case of NFS clients, instead of the server's C libraries
being used, the clients C libraries (and tools they are linked
against) are the issue.  That's how some of us running Linux 2.2.x
with LFS added plus the NFSv3 + LFS backport, could allow >2GB files
from 64-bit client architectures (like Solaris/SPARC).  If you used
"dump" for your backup, you had no issues (whereas tar and other
utilities might).

-- TheBS

--
Bryan "TheBS" Smith          chat:thebs413 @AOL/MSN/Yahoo
Engineer      mailto:b.j.smith@xxxxxxxx,thebs@xxxxxxxxxxx
*********************************************************
"Never apply a Star Trek solution to a Babylon 5 problem"
                                    -- Nicholas C. Weaver

<Prev in Thread] Current Thread [Next in Thread>