On Thu, Jan 24, 2013 at 09:59:59AM +0100, Arkadiusz Miśkiewicz wrote: > On Thursday 24 of January 2013, Dave Chinner wrote: > > > which, as you can see, mounts as inode32 just fine. Let's make that > > a 500g filesystem on the same device: > > > > $ sudo mkfs.xfs -f -l size=131072b,sunit=8 -d size=500g /dev/vdc > > meta-data=/dev/vdc isize=256 agcount=4, agsize=32768000 > > blks = sectsz=512 attr=2, projid32bit=0 data = > > bsize=4096 blocks=131072000, imaxpct=25 = > > sunit=0 swidth=0 blks > > naming =version 2 bsize=4096 ascii-ci=0 > > log =internal log bsize=4096 blocks=131072, version=2 > > = sectsz=512 sunit=1 blks, lazy-count=1 > > realtime =none extsz=4096 blocks=0, rtextents=0 > > $ sudo mount -o inode32 /dev/vdc /mnt/scratch > > $ grep /mnt/scratch /proc/mounts > > /dev/vdc /mnt/scratch xfs rw,relatime,attr2,inode64,noquota 0 0 > > $ > > > > It reports inode64 just like it should - inode32 was ignored because > > the filesystem is not large enough to create 64 bit inodes, and so > > is using the inode64 allocation behaviour. It's been like this for > > 15 years... ;) > > "Will switch" as in when I mount 500GB fs with inode32 option (/proc/mounts > shows inode64 as in above example), then I do grow lvm under and do > xfs_growfs. Will it magically start reporting inode32 (and using inode32 > allocator) then? It is supposed to - there was one flag in the struct xfs_mount m_flags field for the mount option and another for the actual use of the if the size of the filesystem warranted it. And growing the filesystem is supposed to honour the mount option flag when the inode size boundary is crossed. I don't know if that was tested when the latest set of changes went in. I just had a quick look and I suspect it is now broken given that the xfs_set_inode64() function clears both flags.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
