On Mon, Oct 09, 2006 at 12:32:14PM +0100, David Howells wrote: > David Chinner <dgc@xxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
