Initial mount with inode32 option

[Dave Chinner]

On Wed, Jan 23, 2013 at 05:22:44PM -0600, Ben Myers wrote:
> Hi Harry,
> 
> On Wed, Jan 23, 2013 at 03:07:42PM -0800, Harry Edmon wrote:
> > It appears that "mount -o inode32 /dev/sda1 /mnt" ignores the
> > inode32 option and mounts with inode64.   After the partition is
> > mounted I can do "mount -o remount,inode32 /mnt" and it remounts
> > with inode32.   But shouldn't there be a way to do the initial mount
> > with inode32?   I am running Linux 3.7.3 on an amd architecture.   I
> > would like this option since I am using EMC Networker for backups
> > (yes, I know about the complaints).  Thanks.
> 
> # mount -o inode32 /dev/sdb1 /mnt/scratch
> # grep /dev/sdb1 /proc/mounts
> /dev/sdb1 /mnt/scratch xfs rw,relatime,attr2,inode64,noquota 0 0
> # mount -o remount,inode32 /mnt/scratch
> # grep /dev/sdb1 /proc/mounts
> /dev/sdb1 /mnt/scratch xfs rw,relatime,attr2,inode32,noquota 0 0
> 
> We'll get this fixed.

That's not necessarily broken. Filesystems under 1TB will always
report inode64. filesytsems will only switch to inode32 (regardless
of the mount option) when they go above the size that will cause
inodes to exceed 32 bits.

e.g. a 17TB filesytem:

$ sudo mkfs.xfs -f -l size=131072b,sunit=8 /dev/vdc
meta-data=/dev/vdc               isize=256    agcount=17, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=4563402735, imaxpct=5
         =                       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,inode32,noquota 0 0
$

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... ;)

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com