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? > Cheers, > > Dave. -- Arkadiusz Miśkiewicz, arekm / maven.pl _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
