xfs
[Top] [All Lists]

Re: 64 bit status report

To: Phil Schwan <phil@xxxxxxxxxxxxx>
Subject: Re: 64 bit status report
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Fri, 07 Apr 2000 11:24:17 -0500
Cc: linux-xfs@xxxxxxxxxxx
References: <20000406233919.I11090@xxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Phil Schwan wrote:

> Since we're on the topic of status reports, I'll try to tell you where
> I'm at with the big filesystem stuff.
>
> In terms of big files, there are no problems, as long as you're
> running a suitably new glibc.  I've created sparse files larger than 4
> TB (if the very nice Purolator man brings me a magical giant disk
> array, I'll test non-sparse files too) without any apparent ill
> effects.
>
> [root@caesar xfs]# ls -l /mnt/xfs/test
> -rwxr-xr--    1 root     root     5344754401280 Apr  6 19:15 /mnt/xfs/test
> [root@caesar xfs]#
>
> Now, as far as 64 bit inode numbers go, the story is somewhat
> different (as expected).  Unfortunately, glibc unconditionally defines
> __ino64_t to be unsigned long, despite any LARGEFILE64_SOURCE or
> whatever.
>
> As an alternative to dealing with the political mess that wedging
> a 64 bit ino_t into glibc and the kernel, Steve pondered some ideas
> about doing all of the 64 bit work internal to XFS.  Unfortunately,
> one of the big things that I think it would break is NFS, which
> (currently) relies on an inode being a unique file identifier.
>
> As someone who would rather see 64 bit ino_ts, even if it takes a long
> time and a bunch of fighting, I've sent off some emails to the glibc
> folks, just to see if they've even been considering this.  Hopefully
> I'll hear back from them shortly, and see where to go from there.
>
> Thoughts?
>

I think we may have to attack on several fronts.
Simplistic case:
since most people are not going to put XFS
up a  2TB (well not to next year when Seagate introduces their 1TB drives :-)

make XFS work in the current environment to the best we can.
i.e. no crashes, correct error messages when things  do fail to fit in a
container.
Probably add a check in mkfs to warn people about upgrading glibc if
the size of the file system they are trying to make is over 2TB.


Long term we should start the process of modifying glibc and all the
shell/file/bin utils
that may be affected by type changes., and NFS?... ugghh that doesn't sound
like fun.
This was not an easy process on IRIX  I suspect it will be a lot work for
linux also;
mostly in terms of providing compatibility and transition interfaces.

-Russell






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