This past week I created a new XFS file system to test a feature and received the following error when I tried to mount it:
$ mount /dev/mapper/lv01 /disks/lv01
mount: wrong fs type, bad option, bad superblock on /dev/mapper/lv01,
missing codepage or helper program, or other error
The file system was created with the default options and the output of xfs_info looked good:
meta-data=/dev/mapper/lv01 isize=256 agcount=4, agsize=6553600 blks = sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=26214400, imaxpct=25
= sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=12800, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
The system had an existing XFS file system mounted so I decided to compare the metadata from the working file system with the one I just created. This showed one subtle differences:
meta-data=/dev/mapper/vg-var isize=256 agcount=4, agsize=131072 blks
= sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 spinodes=0
data = bsize=4096 blocks=524288, imaxpct=25 = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
The working file system had the crc and ftype flags set to 0 while the non-working file system had crc set to 0 and ftype set to 1 (these are the defaults for the version of xfsprogs I was using). Re-creating the file system with ftype=0 allowed the file system to mount. I’m not one to sit back and enjoy a victory and move on. I wanted to know WHY it failed and the implications of setting ftype to 0. The mkfs.xfs manual page provides the following description for the ftype flag:
ftype=value This feature allows the inode type to be stored in the directory structure so that the readdir(3) and getdents(2) do not need to look up the inode to determine the inode type.
The value is either 0 or 1, with 1 signifiying that filetype information will be stored in the directory structure. The default value is 0.
When CRCs are enabled via -m crc=1, the ftype functionality is always enabled. This feature can not be turned off for such filesystem configurations.
I took this information and started to dig around to see when this feature was added to the Linux kernel. In Linux kernel 3.10 the XFS file system team added the foundation to perform CRC32 metadata checksums. You can read a great write up on this on the LKML. In Linux kernel 3.13 Ben Myers submitted a number of XFS patches which included the “add the inode directory type support to XFS_IOC_FSGEOM” change. This change added support to allow the inode type to be stored in the structure used to represent a directory in XFS.
The system I was running contained a version of xfsprogs that supported this feature but the xfs kernel module didn’t. Hence the file system creation worked but the kernel barfed when it tried to parse the file system metadata (the Linux kernel xfs_mount.c source was extremely useful for understanding what the error meant). Fortunately newer versions of xfsprogs enable CRC metadata checksumming by default which is a nice step towards achieving what ZFS introduced to the world several years ago. If you are interested in learning more about XFS I would highly recommend adding XFS Filesystem Structure to your reading queue.