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

["Myklebust, Trond" <Trond.Myklebust@netapp.com>]

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