fs/xfs/libxfs/xfs_log_format.h
Source file repositories/reference/linux-study-clean/fs/xfs/libxfs/xfs_log_format.h
File Facts
- System
- Linux kernel
- Corpus path
fs/xfs/libxfs/xfs_log_format.h- Extension
.h- Size
- 36552 bytes
- Lines
- 1087
- Domain
- Core OS
- Bucket
- VFS And Filesystem Core
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct xfs_mountstruct xfs_trans_resstruct xfs_unmount_log_formatstruct xlog_op_headerstruct xlog_rec_ext_headerstruct xlog_rec_headerstruct xfs_trans_headerstruct xfs_inode_log_formatstruct xfs_inode_log_format_32struct xfs_log_legacy_timestampstruct xfs_log_dinodestruct xfs_buf_log_formatstruct xfs_extentstruct xfs_extent_32struct xfs_extent_64struct xfs_efi_log_formatstruct xfs_efi_log_format_32struct xfs_efi_log_format_64struct xfs_efd_log_formatstruct xfs_efd_log_format_32struct xfs_efd_log_format_64struct xfs_map_extentstruct xfs_rui_log_formatstruct xfs_rud_log_formatstruct xfs_phys_extentstruct xfs_cui_log_formatstruct xfs_cud_log_formatstruct xfs_bui_log_formatstruct xfs_bud_log_formatstruct xfs_xmi_log_formatstruct xfs_xmd_log_formatstruct xfs_dq_logformatstruct xfs_qoff_logformatstruct xfs_icreate_logstruct xfs_attri_log_formatstruct xfs_attrd_log_formatenum xfs_blftfunction XFS_LSN_CMPfunction xlog_assign_lsnfunction xlog_get_cyclefunction xfs_ilog_fbrootfunction xfs_ilog_fextfunction xfs_ilog_fdatafunction xfs_blft_to_flagsfunction xfs_blft_from_flagsfunction xfs_efi_log_format_sizeoffunction xfs_efi_log_format32_sizeoffunction xfs_efi_log_format64_sizeof
Annotated Snippet
struct xfs_unmount_log_format {
uint16_t magic; /* XLOG_UNMOUNT_TYPE */
uint16_t pad1;
uint32_t pad2; /* may as well make it 64 bits */
};
/*
* Flags to log operation header
*
* The first write of a new transaction will be preceded with a start
* record, XLOG_START_TRANS. Once a transaction is committed, a commit
* record is written, XLOG_COMMIT_TRANS. If a single region can not fit into
* the remainder of the current active in-core log, it is split up into
* multiple regions. Each partial region will be marked with a
* XLOG_CONTINUE_TRANS until the last one, which gets marked with XLOG_END_TRANS.
*
*/
#define XLOG_START_TRANS 0x01 /* Start a new transaction */
#define XLOG_COMMIT_TRANS 0x02 /* Commit this transaction */
#define XLOG_CONTINUE_TRANS 0x04 /* Cont this trans into new region */
#define XLOG_WAS_CONT_TRANS 0x08 /* Cont this trans into new region */
#define XLOG_END_TRANS 0x10 /* End a continued transaction */
#define XLOG_UNMOUNT_TRANS 0x20 /* Unmount a filesystem transaction */
struct xlog_op_header {
__be32 oh_tid; /* transaction id of operation : 4 b */
__be32 oh_len; /* bytes in data region : 4 b */
__u8 oh_clientid; /* who sent me this : 1 b */
__u8 oh_flags; /* : 1 b */
__u16 oh_res2; /* 32 bit align : 2 b */
};
/* valid values for h_fmt */
#define XLOG_FMT_UNKNOWN 0
#define XLOG_FMT_LINUX_LE 1
#define XLOG_FMT_LINUX_BE 2
#define XLOG_FMT_IRIX_BE 3
/* our fmt */
#ifdef XFS_NATIVE_HOST
#define XLOG_FMT XLOG_FMT_LINUX_BE
#else
#define XLOG_FMT XLOG_FMT_LINUX_LE
#endif
struct xlog_rec_ext_header {
__be32 xh_cycle; /* write cycle of log */
__be32 xh_cycle_data[XLOG_CYCLE_DATA_SIZE];
__u8 xh_reserved[252];
};
/* actual ext header payload size for checksumming */
#define XLOG_REC_EXT_SIZE \
offsetofend(struct xlog_rec_ext_header, xh_cycle_data)
struct xlog_rec_header {
__be32 h_magicno; /* log record (LR) identifier : 4 */
__be32 h_cycle; /* write cycle of log : 4 */
__be32 h_version; /* LR version : 4 */
__be32 h_len; /* len in bytes; should be 64-bit aligned: 4 */
__be64 h_lsn; /* lsn of this LR : 8 */
__be64 h_tail_lsn; /* lsn of 1st LR w/ buffers not committed: 8 */
__le32 h_crc; /* crc of log record : 4 */
__be32 h_prev_block; /* block number to previous LR : 4 */
__be32 h_num_logops; /* number of log operations in this LR : 4 */
__be32 h_cycle_data[XLOG_CYCLE_DATA_SIZE];
/* fields added by the Linux port: */
__be32 h_fmt; /* format of log record : 4 */
uuid_t h_fs_uuid; /* uuid of FS : 16 */
/* fields added for log v2: */
__be32 h_size; /* iclog size : 4 */
/*
* When h_size added for log v2 support, it caused structure to have
* a different size on i386 vs all other architectures because the
* sum of the size ofthe member is not aligned by that of the largest
* __be64-sized member, and i386 has really odd struct alignment rules.
*
* Due to the way the log headers are placed out on-disk that alone is
* not a problem becaue the xlog_rec_header always sits alone in a
* BBSIZEs area, and the rest of that area is padded with zeroes.
* But xlog_cksum used to calculate the checksum based on the structure
* size, and thus gives different checksums for i386 vs the rest.
* We now do two checksum validation passes for both sizes to allow
* moving v5 file systems with unclean logs between i386 and other
* (little-endian) architectures.
*/
__u32 h_pad0;
Annotation
- Detected declarations: `struct xfs_mount`, `struct xfs_trans_res`, `struct xfs_unmount_log_format`, `struct xlog_op_header`, `struct xlog_rec_ext_header`, `struct xlog_rec_header`, `struct xfs_trans_header`, `struct xfs_inode_log_format`, `struct xfs_inode_log_format_32`, `struct xfs_log_legacy_timestamp`.
- Atlas domain: Core OS / VFS And Filesystem Core.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.