Re: Extended file stat: Splitting file- and fs-specific info?

On Tue, 2012-05-08 at 21:19 +0100, David Howells wrote:

Should I split the file-specific info and the fs-specific info and make the
second optional?  What I'm thinking of is something like this:

Have a file information structure:

struct statx {
	/* 0x00 */
	uint32_t	st_mask;	/* What results were written */
	uint32_t	st_information;	/* Information about the file */
	uint16_t	st_mode;	/* File mode */
	uint16_t	__spare0[3];
	/* 0x10 */
	uint32_t	st_uid;		/* User ID of owner */
	uint32_t	st_gid;		/* Group ID of owner */
	uint32_t	st_nlink;	/* Number of hard links */
	uint32_t	st_blksize;	/* Optimal size for filesystem I/O */
	/* 0x20 */
	struct statx_dev st_rdev;	/* Device ID of special file */
	struct statx_dev st_dev;	/* ID of device containing file */
	/* 0x30 */
	int32_t		st_atime_ns;	/* Last access time (ns part) */
	int32_t		st_btime_ns;	/* File creation time (ns part) */
	int32_t		st_ctime_ns;	/* Last attribute change time (ns part) */
	int32_t		st_mtime_ns;	/* Last data modification time (ns part) */
	/* 0x40 */
	int64_t		st_atime;	/* Last access time */
	int64_t		st_btime;	/* File creation time */
	int64_t		st_ctime;	/* Last attribute change time */
	int64_t		st_mtime;	/* Last data modification time */
	/* 0x60 */
	uint64_t	st_ino;		/* Inode number */
	uint64_t	st_size;	/* File size */

Should we consider making the st_size and st_blocks 128-bit values while
we're at it? Alternatively, we could add an st_ioc_flag for it later...

	uint64_t	st_blocks;	/* Number of 512-byte blocks allocated */
	uint64_t	st_gen;		/* Inode generation number */
	uint64_t	st_version;	/* Data version number */
	uint64_t	st_ioc_flags;	/* As FS_IOC_GETFLAGS */
	/* 0x90 */
	uint64_t	__spare1[13];	/* Spare space for future expansion */
	/* 0x100 */
};

And an fs information structure for less commonly needed data:

struct statx_fsinfo {
	/* 0x00 - General info */
	uint32_t	st_mask;	/* What optional fields are filled in */
	uint32_t	st_type;	/* Filesystem type from linux/magic.h */

	/* 0x08 - file timestamp granularity info */
	uint16_t	st_atime_gran_mantissa;	/* gran(secs) = mant * 10^exp */
	uint16_t	st_btime_gran_mantissa;
	uint16_t	st_ctime_gran_mantissa;
	uint16_t	st_mtime_gran_mantissa;
	/* 0x10 */
	int8_t		st_atime_gran_exponent;
	int8_t		st_btime_gran_exponent;
	int8_t		st_ctime_gran_exponent;
	int8_t		st_mtime_gran_exponent;

	/* 0x14 - I/O parameters */
	uint32_t	st_blksize;	  /* File block size */
	uint32_t	st_alloc_blksize; /* Allocation block size/alignment */
	uint32_t	st_small_io_size; /* IO size/alignment that avoids fs/page cache RMW */
	uint32_t	st_pref_io_size;  /* Preferred IO size for general usage */
	uint32_t	st_large_io_size; /* IO size/alignment for high bandwidth sequential IO */

	/* 0x28 - Restrictions on struct statx contents */
	uint64_t	st_supported_ioc_flags; /* FS_IOC_GETFLAGS flags supported  */

	/* 0x30 - Volume/filesystem information */
	uint64_t	st_fsid;	/* Short 64-bit Filesystem ID (as statfs) */
	uint64_t	__spare0[3];
	/* 0x50 */
	uint8_t		st_volume_id[16]; /* Volume/fs identifier */
	uint8_t		st_volume_uuid[16]; /* Volume/fs UUID */
	/* 0x80 */
	uint64_t	__spare1[8];
	/* 0xc0 */
	uint8_t		st_volume_name[64]; /* Volume name (up to 64 chars) */
	/* 0x100 */
	uint8_t		st_domain_name[256]; /* Domain/cell/workgroup name (up to 256 chars) */
	/* 0x200 */
};

If you are making a separate fsinfo structure, then it would be nice to
have flags to indicate what kind of acls the filesystem supports, and if
it supports features such as xattrs, subfiles and/or snapshots.



-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com