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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
