O_DIRECT alignment is not one size: typically 4096 bytes on Linux 2.4, typically 512 bytes on Linux 2.6.0

The fault is reading typically 4096 bytes, or typically 512 bytes, as the alignment of every O_DIRECT transfer. open(2) places typically 4096 bytes on Linux 2.4, for most filesystems based on block devices, as the filesystem block size that the file offset, the length, and the memory address of all I/O segments must be a multiple of. It places typically 512 bytes on the Linux 2.6.0 relaxation, as the logical block size of the block device. The same NOTES section says that in Linux alignment restrictions vary by filesystem and kernel version and might be absent entirely. It also says that if statx and a filesystem-specific query are unavailable, alignment can only be assumed from the filesystem, the individual file, the underlying storage device, and the kernel version. The Linux NFS client is the counterexample printed on that page: it places no alignment restrictions on O_DIRECT I/O. That sentence does not print a byte size. statx(2) uses 0 for a different fact, that direct I/O is not supported on the file.

The signal that catches a per-file rule, since Linux 6.1, is statx(2) with STATX_DIOALIGN. The mask requests stx_dio_mem_align and stx_dio_offset_align. stx_dio_mem_align is the alignment in bytes for user memory buffers. stx_dio_offset_align is the alignment in bytes for file offsets and I/O segment lengths. Each is nonzero only when the other is nonzero. statx(2) says the query is supported on block devices since Linux 6.1, and on regular files by ext4, f2fs, and xfs since Linux 6.1, with other regular-file support varying by filesystem. open(2) says the same flag is how O_DIRECT support and alignment restrictions for a file can be queried, and that support varies by filesystem. A logical block size from the ioctl BLKSSZGET, or from blockdev --getss, is the device figure open(2) names behind the 512-byte parenthetical. Those commands were not run here. Their result would not be stx_dio_offset_align, and it would not say that a filesystem's restriction is absent.

That query misses a transfer that succeeded and was not direct. open(2) says misaligned O_DIRECT I/Os can fail with EINVAL or fall back to buffered I/O, so a successful call does not prove the I/O stayed direct. A different EINVAL is open() failing because the filesystem does not implement O_DIRECT. Kernels older than the flag ignore it: support was added in Linux 2.4.10, and older Linux kernels simply ignore the flag. statx(2) says that, in general, the kernel does not reject mask bits other than the reserved one, and reports support in stx_mask. The reserved-flag EINVAL is STATX__RESERVED, value 0x80000000U. An unsupported STATX_DIOALIGN request is not described as that EINVAL, and a clear stx_mask bit is not an alignment of 4096 or 512. Since Linux 6.14 the read path can use another field. If stx_dio_read_offset_align is zero, the limit in stx_dio_offset_align applies for reads as well. If non-zero, it must be smaller than or equal to stx_dio_offset_align, and stx_dio_mem_align is not affected. The support sentence prints STATX_DIO_READ_ALIGN (stx_dio_offset_align) for xfs on regular files since Linux 6.14. The mask line names stx_dio_read_offset_align. Both sentences stay as printed.

Alignment does not catch a durability failure. In the O_DIRECT flag description, open(2) says the flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred. To guarantee synchronous I/O, O_SYNC must be used in addition to O_DIRECT. Under NOTES, the NFS protocol does not pass the flag to the server, so O_DIRECT bypasses the page cache only on the client, and the server may still cache the I/O. The same paragraph says some servers may be configured to lie to clients about the I/O having reached stable storage. Those sentences are not a throughput, and they are not properties of the 4096-byte or 512-byte rows. The Synchronized I/O section's date for O_SYNC before Linux 2.6.33 is a different section and is not moved onto those rows.