IOCTL-XFS-BULKSTAT(2)

🦋 NAME 🦋

okay so this is ioctl_xfs_bulkstat(2), bestie — a Linux system call manual page (System Calls Manual, if we're being official about it) — and it's all about how you query information for a whole batch of XFS inodes at once. no cap.

---

✨ SYNOPSIS ✨

#include <xfs/xfs_fs.h>

int ioctl(int fd, XFS_IOC_BULKSTAT, struct xfs_bulkstat_req *arg);

---

🌸 DESCRIPTION 🌸

So the whole vibe here is: you want stat info for a group of XFS inodes, not just one lonely little guy. This ioctl uses a struct xfs_bulkstat_req to set up a bulk transfer straight from the kernel, like a little assembly line of inode facts:

struct xfs_bulkstat_req {
     struct xfs_bulk_ireq    hdr;
     struct xfs_bulkstat     bulkstat[];
};

And the xfs_bulkstat structure definition? It's coming, keep scrolling, bestie, it's right below. 👇

struct xfs_bulk_ireq {
     uint64_t                ino;
     uint32_t                flags;
     uint32_t                icount;
     uint32_t                ocount;
     uint32_t                agno;
     uint64_t                reserved[5];
};

So hdr.ino — you set that to the number of the first inode you want info on. Or set it to zero and you start with the very first inode in the filesystem. OR, plot twist, set it to a special value if XFS_BULK_IREQ_SPECIAL is set in the flags field. 🫢 Heads up though: this is a different semantic than the lastip in the old FSBULKSTAT ioctl, so don't get it twisted. After the call goes through, this value gets set to the number of the next inode for which information could be supplied — which lowkey sets you up perfectly for the next call in your iteration loop. slay.

If the XFS_BULK_IREQ_SPECIAL flag is set in the flags field, then the ino field gets interpreted according to these special values:

• XFS_BULK_IREQ_SPECIAL_ROOT — Return stat information for the root directory inode. the root dir is the main character fr.

hdr.flags is a bit set of operational flags, and here's the whole menu:

• XFS_BULK_IREQ_AGNO — If this is set, the call will only return results for the allocation group (AG) set in hdr.agno. If hdr.ino is set to zero, results will be returned starting with the first inode in the AG. This flag may not be set at the same time as the XFS_BULK_IREQ_SPECIAL flag.
• XFS_BULK_IREQ_SPECIAL — If this is set, results will be returned for only the special inode specified in the hdr.ino field. This flag may not be set at the same time as the XFS_BULK_IREQ_AGNO flag.
• XFS_BULK_IREQ_NREXT64 — If this is set, data fork extent count is returned via the bs_extents64 field and 0 is assigned to bs_extents. Otherwise, data fork extent count is returned via the bs_extents field and bs_extents64 is assigned a value of 0. In that second case, bs_extents is set to (2^31 - 1) if the data fork extent count is larger than 2^31. This flag may be set independently of whether other flags have been set.
• XFS_BULK_IREQ_METADIR — Return metadata directory tree inodes in the stat output as well. The only fields that will be populated are bs_ino, bs_gen, bs_mode, bs_sick, and bs_checked. All other fields, notably bs_blksize, will be zero. 🙈 don't come for those fields, they're literally not invited.

hdr.icount is the maximum number of records to return — and yeah, this should be the size of the array that comes after the header. keep it consistent bestie.

hdr.ocount will be set to the number of records actually returned. (the receipts. 🧾)

hdr.agno is the number of the allocation group (AG) for which we want results. But if the XFS_BULK_IREQ_AGNO flag is not set, this field is just ignored. it's giving decorative.

hdr.reserved must be set to zero. no notes, just zero.

bulkstat is an array of struct xfs_bulkstat, which is described right here, and the array must have at least icount elements:

struct xfs_bulkstat {
     uint64_t                bs_ino;
     uint64_t                bs_size;

     uint64_t                bs_blocks;
     uint64_t                bs_xflags;

     uint64_t                bs_atime;
     uint64_t                bs_mtime;

     uint64_t                bs_ctime;
     uint64_t                bs_btime;

     uint32_t                bs_gen;
     uint32_t                bs_uid;
     uint32_t                bs_gid;
     uint32_t                bs_projectid;

     uint32_t                bs_atime_nsec;
     uint32_t                bs_mtime_nsec;
     uint32_t                bs_ctime_nsec;
     uint32_t                bs_btime_nsec;

     uint32_t                bs_blksize;
     uint32_t                bs_rdev;
     uint32_t                bs_cowextsize_blks;
     uint32_t                bs_extsize_blks;

     uint32_t                bs_nlink;
     uint32_t                bs_extents;
     uint32_t                bs_aextents;
     uint16_t                bs_version;
     uint16_t                bs_forkoff;

     uint16_t                bs_sick;
     uint16_t                bs_checked;
     uint16_t                bs_mode;
     uint16_t                bs_pad2;
     uint64_t                bs_extents64;

     uint64_t                bs_pad[6];
};

okay field-by-field tour, come on, let's go 🚶‍♀️✨

• bs_ino is the inode number of this record.
• bs_size is the size of the file, in bytes.
• bs_blocks is the number of filesystem blocks allocated to this file, including metadata.
• bs_xflags tell us what extended flags are set on this inode. These flags are the same values as those defined in the XFS INODE FLAGS section of the ioctl_xfs_fsgetxattr(2) manpage. (go peek at that one, iykyk 💅)
• bs_atime is the last time this file was accessed, in seconds.
• bs_mtime is the last time the contents of this file were modified, in seconds.
• bs_ctime is the last time this inode record was modified, in seconds.
• bs_btime is the time this inode record was created, in seconds.
• bs_gen is the generation number of the inode record.
• bs_uid is the user id.
• bs_gid is the group id.
• bs_projectid is the the project id. (yes, that double "the" is in the original, we're leaving it, it's iconic 💀)
• bs_atime_nsec is the nanoseconds component of the last time this file was accessed.
• bs_mtime_nsec is the nanoseconds component of the last time the contents of this file were modified.
• bs_ctime_nsec is the nanoseconds component of the last time this inode record was modified.
• bs_btime_nsec is the nanoseconds component of the time this inode record was created.
• bs_blksize is the size of a data block for this file, in units of bytes.
• bs_rdev is the encoded device id if this is a special file.
• bs_cowextsize_blks is the Copy on Write extent size hint for this file, in units of data blocks.
• bs_extsize_blks is the extent size hint for this file, in units of data blocks.
• bs_nlink is the number of hard links to this inode.
• bs_extents is the number of storage mappings associated with this file's data.
• bs_aextents is the number of storage mappings associated with this file's extended attributes.
• bs_version is the version of this data structure. This will be set to XFS_BULKSTAT_VERSION_V5 by the kernel. ✨
• bs_forkoff is the offset of the attribute fork in the inode record, in bytes.
• The fields bs_sick and bs_checked indicate the relative health of various allocation group metadata. Please see the section XFS INODE METADATA HEALTH REPORTING for more information. 🩺 (that's right, we're getting a whole health check section, stay tuned)
• bs_mode is the file type and mode.
• bs_pad[7] is zeroed.

---

💫 RETURN VALUE 💫

On error, -1 is returned, and errno is set to indicate the error. classic.

---

🩺 XFS INODE METADATA HEALTH REPORTING 🩺

The online filesystem checking utility scans inode metadata and records what it finds in the kernel incore state. So here's the scheme that lets userspace read the incore health status of an inode — it's giving doctor's chart:

• If a given sick flag is set in bs_sick, then that piece of metadata has been observed to be damaged. The same bit should be set in bs_checked. 😭
• If a given sick flag is set in bs_checked but is not set in bs_sick, then that piece of metadata has been checked and is not faulty. healthy queen 👑
• If a given sick flag is not set in bs_checked, then no conclusion can be made. shrug, the data simply isn't there.

The following flags apply to these fields:

• XFS_BS_SICK_INODE — The inode's record itself.
• XFS_BS_SICK_BMBTD — File data extent mappings.
• XFS_BS_SICK_BMBTA — Extended attribute extent mappings.
• XFS_BS_SICK_BMBTC — Copy on Write staging extent mappings.
• XFS_BS_SICK_DIR — Directory information.
• XFS_BS_SICK_XATTR — Extended attribute data.
• XFS_BS_SICK_SYMLINK — Symbolic link target.
• XFS_BS_SICK_PARENT — Parent pointers.
• XFS_BS_SICK_DIRTREE — Directory is the source of corruption in the directory tree.

---

🚨 ERRORS 🚨

Error codes can be one of, but are not limited to, the following — so don't assume the list is closed, bestie:

• EFAULT — The kernel was not able to copy into the userspace buffer.
• EFSBADCRC — Metadata checksum validation failed while performing the query.
• EFSCORRUPTED — Metadata corruption was encountered while performing the query.
• EINVAL — One of the arguments was not valid.
• EIO — An I/O error was encountered while performing the query.
• ENOMEM — There was insufficient memory to perform the query.

---

🌈 CONFORMING TO 🌈

This API is specific to XFS filesystem on the Linux kernel. no portability tea here, it's a Linux-XFS exclusive 💅

---

👀 SEE ALSO 👀

ioctl(2), ioctl_xfs_fsgetxattr(2)

---

okay that's the whole page, you ate that 🫶 this lil gem comes from the XFS manual collection and it's dated 2019-05-23 — so yeah, it's been serving accurate inode facts since then, no cap. go forth and bulkstat, bestie 💖✨🎀