IOCTL-XFS-GETBMAPX(2)

πŸ’– ioctl_xfs_getbmapx β€” like, the System Calls Manual page for querying extent info πŸ’–

okay so bestie, welcome to ioctl_xfs_getbmapx, straight out of the System Calls Manual. it's a little query tool that asks an open file "hey, where do your blocks actually live?" and XFS answers. no cap. let's get into it πŸ¦‹


✨ NAME ✨

ioctl_xfs_getbmapx β€” query extent information for an open file


🌸 SYNOPSIS 🌸

#include <xfs/xfs_fs.h>

int ioctl(int fd, XFS_IOC_GETBMAP, struct getbmap *arg);
int ioctl(int fd, XFS_IOC_GETBMAPA, struct getbmap *arg);
int ioctl(int fd, XFS_IOC_GETBMAPX, struct getbmapx *arg);

πŸ‘‘ DESCRIPTION πŸ‘‘

So basically, this gets you the block map for a segment of a file living in an XFS file system. The mapping info gets handed back to you through an array of structs that look like this, periodt:

struct getbmap {
     __s64   bmv_offset;
     __s64   bmv_block;
     __s64   bmv_length;
     __s32   bmv_count;
     __s32   bmv_entries;
};

And the XFS_IOC_GETBMAPX ioctl is just the glow-up version β€” it uses a bigger, more main-character struct:

struct getbmapx {
     __s64   bmv_offset;
     __s64   bmv_block;
     __s64   bmv_length;
     __s32   bmv_count;
     __s32   bmv_entries;
     __s32   bmv_iflags;
     __s32   bmv_oflags;
     __s32   bmv_unused1;
     __s32   bmv_unused2;
};

πŸ“ Important vibe check: all sizes and offsets in the structure are in units of 512 bytes. don't forget it iykyk.

The first struct in the array is the header, and the rest of the structs in the array get filled with block map info when the call returns. The header is the one steering those iterative calls, so fill it out like this:

  • bmv_offset β€” the file offset of the area of interest in the file.
  • bmv_length β€” the length of the area of interest in the file. set it to -1 and the interesting area is just the rest of the file, easy peasy 🌈
  • bmv_count β€” the number of elements in the array, including this header. minimum value is 2. that's the floor, bestie.
  • bmv_entries β€” the number of entries actually filled in by the call. you don't need to fill this out before the call. it can be zero if no extents were found in the requested range, or if iterated calls have reached the end of the requested range.
  • bmv_iflags β€” for the XFS_IOC_GETBMAPX function, this is a bitmask holding a combo of these flags:
    • BMV_IF_ATTRFORK β€” return information about the extended attribute fork.
    • BMV_IF_PREALLOC β€” return information about unwritten pre-allocated segments.
    • BMV_IF_DELALLOC β€” return information about delayed allocation reservation segments.
    • BMV_IF_NO_HOLES β€” do not return information about holes.

The other bmv_* fields in the header are just... ignored. literally nobody's looking at them πŸ’€

When a call returns successfully, the offset and length values in the header get updated so you can reuse the command to grab more info β€” it's giving efficient, it's giving recycling ♻️. The remaining elements of the array get filled out by the call like so:

  • bmv_offset β€” file offset of segment.
  • bmv_block β€” physical starting block of segment. if this is -1, then the segment is a hole. (a hole!! 😭)
  • bmv_length β€” length of segment.
  • bmv_oflags β€” the XFS_IOC_GETBMAPX function fills this field with a combination of these flags:
    • BMV_OF_PREALLOC β€” the segment is an unwritten pre-allocation.
    • BMV_OF_DELALLOC β€” the segment is a delayed allocation reservation.
    • BMV_OF_LAST β€” this segment is the last in the file. the finale. the last one in the group chat 🫢
    • BMV_OF_SHARED β€” this segment shares blocks with other files.

The other bmv_* fields are unused in the array of output records. just vibing there. unused.

Oh and also πŸŽ€: the XFS_IOC_GETBMAPA command is identical to XFS_IOC_GETBMAP except that information about the attribute fork of the file is returned. that's the whole difference, slay.


⭐ RETURN VALUE ⭐

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


🚨 ERRORS 🚨

Error codes can be one of, but are not limited to, the following:

  • EFAULT β€” the kernel was not able to copy into the userspace buffer. rude of it.
  • 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.
lowkey if you see EFSBADCRC or EFSCORRUPTED, something is genuinely not okay with your metadata. not a vibe. 😭

πŸ’… CONFORMING TO πŸ’…

This API is specific to XFS filesystem on the Linux kernel. exclusive. it's giving XFS-only, no gatekeeping but also no other filesystems πŸ’œ


πŸ”₯ SEE ALSO πŸ”₯


okay that's the whole page bestie, you ate that 🫢 this was XFS, dated 2019-06-17 β€” go forth and map those blocks, mwah πŸ’–βœ¨

πŸ“¦ where this page comes from