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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1336511603.12198.11.camel@lade.trondhjem.org>
Date:	Tue, 8 May 2012 21:13:21 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	David Howells <dhowells@...hat.com>
CC:	"adilger@...ger.ca" <adilger@...ger.ca>,
	"david@...morbit.com" <david@...morbit.com>,
	"bfields@...ldses.org" <bfields@...ldses.org>,
	"smfrench@...il.com" <smfrench@...il.com>,
	"ben@...adent.org.uk" <ben@...adent.org.uk>,
	"roland@...k.frob.com" <roland@...k.frob.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
	"samba-technical@...ts.samba.org" <samba-technical@...ts.samba.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>
Subject: 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@...app.com
www.netapp.com