linux-ext4 - Re: [PATCH 0/6] Extended file stat system call

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]

Date:	Fri, 27 Apr 2012 11:06:10 +1000
From:	Dave Chinner <david@...morbit.com>
To:	David Howells <dhowells@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-ext4@...r.kernel.org, wine-devel@...ehq.org,
	kfm-devel@....org, nautilus-list@...me.org,
	linux-api@...r.kernel.org, libc-alpha@...rceware.org
Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 19, 2012 at 03:05:58PM +0100, David Howells wrote:
> 
> Implement a pair of new system calls to provide extended and further extensible
> stat functions.
> 
> The second of the associated patches is the main patch that provides these new
> system calls:
> 
> 	ssize_t ret = xstat(int dfd,
> 			    const char *filename,
> 			    unsigned atflag,
> 			    unsigned mask,
> 			    struct xstat *buffer);
> 
> 	ssize_t ret = fxstat(int fd,
> 			     unsigned atflag,
> 			     unsigned mask,
> 			     struct xstat *buffer);
> 
> which are more fully documented in the first patch's description.
> 
> These new stat functions provide a number of useful features, in summary:
> 
>  (1) More information: creation time, inode generation number, data version
>      number, flags/attributes.  A subset of these is available through a number
>      of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).

If we are adding per-inode flags, then what do we do with filesystem
specific flags? e.g. XFS has quite a number of per-inode flags that
don't align with any other filesystem (e.g. filestream allocator,
real time file, behaviour inheritence flags, etc), but may be useful
to retrieve in such a call. We currently have an ioctl to get that
information from each inode. Have you thought about how to handle
such flags?

Along the same lines, filesytsems can have different allocation
constraints to IO the filesystem block size - ext4 with it's
bigalloc hack, XFS with it's per-inode extent size hints and the
realtime device, etc. Then there's optimal IO characteristics
(e.g. geometery hints like stripe unit/stripe width for the
allocation policy of that given file) that applications could use
if they were present rather than having to expose them through
ioctls that nobody even knows about...

Perhaps also exposing the project ID for quota purposes, like we do
UID and GID. That way we wouldn't need a filesystem specific ioctl
to read it....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html