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@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
