Re: 64-bit inode number issues

[David Chinner <dgc@sgi.com>]

On Mon, Oct 09, 2006 at 12:32:14PM +0100, David Howells wrote:
> David Chinner <dgc@sgi.com> wrote:
> 
> > >  o turn it off by default in -mm and see what goes boom
> > 
> > Will we even see the conditions for the NFS client to go boom in the
> > environments -mm kernels are typically run? i.e. does someone have a
> > test case that reliably triggers problems?
> 
> I don't know about that, but we (Red Hat) have had customers logging the
> problem in our Bugzilla against NFS.
> 
> Coming up with a reliable test case is a little tricky, as it involves setting
> up a server to generate fileids > 0xffffffff, and manipulating inode numbers
> directly generally isn't allowed...  Maybe it can be done with a ramfs hack.

64 bit machine, >1TB sized XFS filesystem on the server, inode64
mount option, fill the filesystem to 99% full and then create lots
of inodes. You should get inodes above 1TB then, and that will give
you 64 bit inode numbers.

Typically the way we do this quickly is create an XFS filesystem
then use the ag-wipe tool (*) we have in our QA suite that uses
xfs_db to "fill" up all but the last AG in the filesystem by poking
the right numbers into on disk structures.  This is significantly
faster than filling a terabyte of disk space.....

(*)http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/tools/ag-wipe

FWIW, if you don't have more than a TB of disk space, then you might
be able to create an XFS filesystem on loopback using a sparse file
and then using the ag-wipe tool on the loopback filesystem.

HTH.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group