On Wed, Mar 06, 2013 at 12:48:25AM +0100, Hans-Peter Jansen wrote: > Am Mittwoch, 6. März 2013, 09:29:41 schrieb Dave Chinner: > > On Tue, Mar 05, 2013 at 09:32:02PM +0100, Hans-Peter Jansen wrote: > > attr_list and attr_multi are supplied by libattr, you should not > > need the *by_handle variants at all - they are special sauce used by > > xfsdump, not xfs_reno.... > > Ahh, I see. These interfaces cannot be exercised much, given that google > didn't relate them to libattr prominently.. Attributes are not widely used by applications for some reason... > Hmm, any idea on how xfs can be tricked into generating 64 bit inodes without > the need to create an excessive big test fs, or is this an accepted practice? The usual trick is to use a sparse loopback device and create the filesystem on that. see, for example, xfstests 078, where it is testing growfs on filesystems up to 16TB in size on a loopback device... > Note to myself: xfs_reno could use some mount option check. Forgot to remount > one partition with inode32 and, consequently, moved the offending inodes to > another 64 bit value.. I'd just use a wrapper script that checked /proc/mounts for the inode64 flag being set first.... .... > Index: b/configure.ac > =================================================================== > --- a/configure.ac > +++ b/configure.ac .... The patch looks sane - can you add a commit description and s Signed-off-by line to it, and then we can use it directly.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
