LinuxLists.cc - [PATCH 0/6] Extended file stat system call

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

Andreas Dilger <[email protected]> wrote:

> > The idea was initially proposed as a set of xattrs that could be
> > retrieved with getxattr(), but the general preferance proved to be
> > for new syscalls with an extended stat structure.
>
> I would comment that it was the opposite. It was originally a
> stat()-like extension that degraded into a messy getxattr() mess.

Ummm... No, my first attempt was definitely through getxattr(). You even
commented on it.

> > The fields in struct xstat come in a number of classes:
> >
> > (0) st_dev, st_blksize, st_information.
> >
> > These are local data and are always available.
>
> For the extra two bits it would cost us, I don't think st_blksize
> and st_information should always be returned.

Fair enough.

> st_blksize may be variable for a distributed filesystem,

I wonder if there's a way to make this explicit - or is it something that if
the bit isn't set, you can't use the value in st_blksize. I wonder if this
value always has to be non-zero to make sure existing stat() doesn't explode.

> and some of the fields in st_information (offline) may not be free to access
> either.

True.

David

2012-04-19 17:11:12

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 19, 2012 at 9:05 AM, David Howells <[email protected]> wrote:
>
> Implement a pair of new system calls to provide extended and further extensible
stat functions.
<snip>
> Should the default for a network fs be to do an unconditional (heavyweight)
> stat with a flag to suppress going to the server to update the locally held
> attributes and flushing pending writebacks?

Even though we can use leases (oplocks) to avoid the roundrtrip, it is
probably too expensive to default to forcing a cache flush, especially
when a common case is to get the file creation time or inode number
information (stable vs volatile).

Would it be better to make the stable vs volatile inode number an attribute
of the volume or something returned by the proposed xstat?

> Should things like the Windows Archive, Hidden and System bits be handled
> through IOC flags, perhaps expanded to 64-bits?

Today I export these through an psuedo-xattr in cifs.ko, I am curious how
NTFS and FAT export these on linux.

> ==========
> TO BE DONE
> ==========
>
> Autofs, ntfs, btrfs, ...

Given the overlap in optional attributes between the network
protocol and local NTFS (and ReFS and to a lesser extent FAT)
I would expect cifs.ko and the ntfs implementations
info to map pretty closely.

> I should perhaps use u8/u32/u64 rather than uint8/32/64_t.
>
> Handle remote filesystems being offline and indicate this with
> XSTAT_INFO_OFFLINE.

You already have support for an indicator for offline files (HSM),
would XSTAT_INFO_OFFLINE be intended for the case
where the network session to the server is disconnected
(and in which you case the application does not want to reconnect)?

--
Thanks,

Steve

2012-04-27 01:06:14

[permalink] [raw]

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
[email protected]

2012-04-27 23:54:36

by Paul Eggert

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 04/26/2012 11:25 AM, Roland McGrath wrote:
> What I'd really prefer is a name that is less meaninglessly arcane,

Since people are used to the string "stat", and since this is
about getting related attributes, how about using the string "statr"?
Thus "statrat" could be the syscall that acts like fstatat, but gets
related attributes too.

A bonus of this name is that a "stat rat" is slang
for someone who loves looking at statistics, often
sports statistics. Billy Beane is a stat rat.
Someone who cares about files' statistics is also
a stat rat.

The "r" in "statrat" could stand for "related", or
for "relevant", or for whatever you like.

2012-04-26 13:54:56

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Roland McGrath <[email protected]> wrote:

> I have no comment on the functionality. But "xstat" is probably a poor
> choice of name. There is precedent for that function name with different
> meaning in the userland APIs. (It's a moderately useless meaning inherited
> from SVR4, but regardless overloading a name previously used is unwise.)

I've no particular attachment to the name 'xstat'. If you'd prefer 'statx' I
could go for that.

David

2012-04-27 18:43:57

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 2012-04-26, at 7:06 PM, Dave Chinner wrote:
> 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 (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?

I'm sympathetic to your cause, but I don't want this to degrade into
the same morass that it did last time when every attribute under the
sun was added to the call. The intent is to replace the stat() call
with something that can avoid overhead on filesystems for which some
attributes are expensive, and that applications may not need. Some
common attributes were added that are used by multiple filesystems.

If it is too filesystem-specific, and there is little possibility
that these attributes will be usable on other filesystems, then it
should remain a filesystem specific ioctl() call. If you can make
a case that these attributes have value on a few other filesystems,
and applications are reasonably likely to be able to use them, and
their addition does not make the API overly complex, then suggest
away.

> 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...

There is already "optimal IO size" that the application can use,
how do the geometry hints differ? Userspace is able to handle
st_blksize of several MB in size without problems, and any sane
application will do the IO sized + aligned on multiples of this.

> 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....

This seems reasonable and generic and simple. This is similar to
directory quotas in other filesystems.

Cheers, Andreas

2012-04-26 17:10:51

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 12:09 PM, Steve French <[email protected]> wrote:
> On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond
> <[email protected]> wrote:
>> On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:
>>> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
>>> <[email protected]> wrote:
>>> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
>>> >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
>>> >> <[email protected]> wrote:
>>> >> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
>>> >> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <[email protected]> wrote:
>>> >> >> > Steve French <[email protected]> wrote:
>>> >> >> >
>>> >> >> >> Would it be better to make the stable vs volatile inode number an attribute
>>> >> >> >> of the volume ?or something returned by the proposed xstat?
>>> >> >> >
>>> >> >> > I'm not sure what you mean by a stable vs a volatile inode number.
>>> >> >>
>>> >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
>>> >> >> unique identifier, but in the case of CIFS some old servers don't support the
>>> >> >> calls which return inode numbers (or don't return them for all file system
>>> >> >> types, Windows FAT?) so in these cases cifs has to create inode
>>> >> >> numbers on the fly
>>> >> >> on the client. ? inode numbers created on the client are not "stable" they
>>> >> >> can change on unmount/remount (which can cause problems for backup
>>> >> >> applications).
>>> >> >>
>>> >> >> Similarly NFSv4 does not require that servers always return stable inode numbers
>>> >> >> (that will never change) and introduced a concept of "volatile file handle."
>>> >> >> We have run into this in two cases (there are probably more) -
>>> >> >> Specialized NFS servers
>>> >> >> for HPC which deal with lots of transient inodes, and second those for servers
>>> >> >> which base there inode number on path (Windows NFS?). ?See
>>> >> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
>>> >> >> or the NFSv4 RFC.
>>> >> >>
>>> >> >> Basically the question is whether it is worth reporting a flag on the
>>> >> >> call which returns
>>> >> >> the inode number to indicate that the inode number is "stable" (would not change
>>> >> >> on reboot or reconnection) or "volatile." ? ?Since the majority of NFS
>>> >> >> and SMB2 servers
>>> >> >> can return stable inode numbers, I don't feel strongly about the need
>>> >> >> for an indicator
>>> >> >> of "stable" vs. "volatile" but I mention it because backup and
>>> >> >> migration applications
>>> >> >> mention this (if inode numbers are volatile, they may have to check
>>> >> >> for hardlinks differently
>>> >> >> for example)
>>> >> >
>>> >> > I don't understand. If the filesystem doesn't support real inode
>>> >> > numbers, then why report them at all? What use would an application have
>>> >> > for an inode number that can't be used to identify hard linked files?
>>> >>
>>> >> Well ... you have to have an inode number on the Linux client side even if
>>> >> the server doesn't report them (or has a bug and reports duplicates).
>>> >> If you can't tell hardlinked files apart fix the server (but in the
>>> >> cases where the file systems has this problem the server doesn't usually
>>> >> support hardlinks either).
>>> >>
>>> >> If the server's file system internal structures don't support real inode
>>> >> numbers (such as FAT or a ramdisk) then it either has to make them
>>> >> up based on something like path name or some other attribute of the
>>> >> file on disk.
>>> >>
>>> >> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009
>>> >> query file info is used to query_file_internal_info (the inode number) but
>>> >> what if the server can not report inode numbers (due to a bug) in
>>> >> all cases.
>>> >
>>> > Right, but none of this explains why we need to report these bogus inode
>>> > numbers to the application in the xstat() reply.
>>>
>>> the question is whether the application (backup) would need to know
>>> that the inode numbers are bogus and from my conversations with
>>> guys writing backup software it seems that such data is useful to them.
>>
>> You are still not explaining why they need to know the values at all? If
>> the values are bogus, then don't return them, and don't set the flag
>> that says they are being returned.
>
> I don't know, but assumed it was because it was an easy way
> to index them since the inode numbers even if they "change"
> on remount, are still unique.

if the call allows the inode number not to be returned, that
is probably ok (they can always use the posix stat to get
the client generated one)

--
Thanks,

Steve

2012-04-19 14:07:26

[permalink] [raw]

Subject: [PATCH 3/6] xstat: AFS: Return extended attributes

Return extended attributes from the AFS filesystem. This includes the
following:

(1) The vnode uniquifier as st_gen.

(2) The data version number as st_data_version.

(3) XSTAT_INFO_AUTOMOUNT will be set on automount directories by virtue of
S_AUTOMOUNT being set on the inode. These are referrals to other volumes
or other cells.

(4) XSTAT_INFO_AUTODIR on a directory that does cell lookup for non-existent
names and mounts them (typically mounted on /afs with -o autocell). The
resulting directories are marked XSTAT_INFO_FABRICATED as they do not
actually exist in the mounted AFS directory.

(6) Files, directories and symlinks accessed over AFS are marked
XSTAT_INFO_REMOTE.

(7) XSTAT_INFO_NONSYSTEM_OWNERSHIP is set as the UID and GID retrieved from an
AFS share may not be applicable on the system.

(8) XSTAT_INFO_HAS_ACL is set as AFS directories have ACLs (the UID and GID
are only used through the ACLs) and these ACLs apply to the contents of
the directories.

Signed-off-by: David Howells <[email protected]>
---

fs/afs/inode.c | 29 +++++++++++++++++++++--------
fs/afs/super.c | 7 +++++++
2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index d890ae3..062def2 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -71,9 +71,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key)
inode->i_uid = vnode->status.owner;
inode->i_gid = 0;
inode->i_size = vnode->status.size;
- inode->i_ctime.tv_sec = vnode->status.mtime_server;
- inode->i_ctime.tv_nsec = 0;
- inode->i_atime = inode->i_mtime = inode->i_ctime;
+ inode->i_mtime.tv_sec = vnode->status.mtime_server;
+ inode->i_mtime.tv_nsec = 0;
+ inode->i_atime = inode->i_ctime = inode->i_mtime;
inode->i_blocks = 0;
inode->i_generation = vnode->fid.unique;
inode->i_version = vnode->status.data_version;
@@ -374,16 +374,29 @@ error_unlock:
/*
* read the attributes of an inode
*/
-int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
- struct kstat *stat)
+int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
{
- struct inode *inode;
-
- inode = dentry->d_inode;
+ struct inode *inode = dentry->d_inode;

_enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation);

generic_fillattr(inode, stat);
+
+ stat->result_mask &= ~(XSTAT_ATIME | XSTAT_CTIME | XSTAT_BLOCKS);
+ stat->result_mask |= XSTAT_GEN | XSTAT_VERSION;
+ stat->gen = inode->i_generation;
+ stat->version = inode->i_version;
+
+ if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags))
+ stat->information |= XSTAT_INFO_AUTODIR;
+
+ if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags))
+ stat->information |= XSTAT_INFO_FABRICATED;
+ else
+ stat->information |= XSTAT_INFO_REMOTE;
+
+ stat->information |=
+ XSTAT_INFO_NONSYSTEM_OWNERSHIP | XSTAT_INFO_HAS_ACL;
return 0;
}

diff --git a/fs/afs/super.c b/fs/afs/super.c
index f02b31e..1f13b48 100644
--- a/fs/afs/super.c
+++ b/fs/afs/super.c
@@ -314,6 +314,13 @@ static int afs_fill_super(struct super_block *sb,
sb->s_bdi = &as->volume->bdi;
strlcpy(sb->s_id, as->volume->vlocation->vldb.name, sizeof(sb->s_id));

+ /* construct a volume ID from the AFS volume ID and type */
+ sb->s_volume_id[4] = as->volume->type;
+ sb->s_volume_id[3] = as->volume->vid >> 0;
+ sb->s_volume_id[2] = as->volume->vid >> 8;
+ sb->s_volume_id[1] = as->volume->vid >> 16;
+ sb->s_volume_id[0] = as->volume->vid >> 24;
+
/* allocate the root inode and dentry */
fid.vid = as->volume->vid;
fid.vnode = 1;

2012-04-27 00:51:26

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
> Andreas Dilger <[email protected]> wrote:
> > st_blksize may be variable for a distributed filesystem,

It can be variable for local filesystems, too. XFS will vary the
block size based on the configuration of the inode. e.g. if there is
an extent allocation size hint on the inode, or it's on the realtime
device, and so on. There is no guarantee that from file to file that
it is constant.

> I wonder if there's a way to make this explicit - or is it something that if
> the bit isn't set, you can't use the value in st_blksize.
> I wonder if this
> value always has to be non-zero to make sure existing stat() doesn't explode.

More likely it probably needs to be non-zero to prevent applications
doing division by block size from exploding... ;)

Cheers,

Dave.
--
Dave Chinner
[email protected]

2012-04-19 14:36:07

[permalink] [raw]

Subject: Re: [PATCH 4/6] xstat: NFS: Return extended attributes

T24gVGh1LCAyMDEyLTA0LTE5IGF0IDE1OjA2ICswMTAwLCBEYXZpZCBIb3dlbGxzIHdyb3RlOg0K
PiBSZXR1cm4gZXh0ZW5kZWQgYXR0cmlidXRlcyBmcm9tIHRoZSBORlMgZmlsZXN5c3RlbS4gIFRo
aXMgaW5jbHVkZXMgdGhlDQo+IGZvbGxvd2luZzoNCj4gDQo+ICAoMSkgVGhlIGNoYW5nZSBhdHRy
aWJ1dGUgYXMgc3RfZGF0YV92ZXJzaW9uIGlmIE5GU3Y0Lg0KPiANCj4gICgyKSBYU1RBVF9JTkZP
X0FVVE9NT1VOVCBhbmQgWFNUQVRfSU5GT19GQUJSSUNBVEVEIGFyZSBzZXQgb24gcmVmZXJyYWwg
b3INCj4gICAgICBzdWJtb3VudCBkaXJlY3RvcmllcyB0aGF0IGFyZSBhdXRvbW91bnRlZCB1cG9u
LiAgTkZTIHNob3dzIG9uZSBkaXJlY3RvcnkNCj4gICAgICB3aXRoIGEgZGlmZmVyZW50IEZTSUQs
IGJ1dCB0aGUgbG9jYWwgZmlsZXN5c3RlbSBoYXMgdHdvOiB0aGUgbW91bnRwb2ludA0KPiAgICAg
IGRpcmVjdG9yeSBhbmQgdGhlIHJvb3Qgb2YgdGhlIGZpbGVzeXN0ZW0gbW91bnRlZCB1cG9uIGl0
Lg0KPiANCj4gICgzKSBYU1RBVF9JTkZPX1JFTU9URSBpcyBzZXQgb24gZmlsZXMgYWNxdWlyZWQg
b3ZlciBORlMuDQo+IA0KPiBGdXJ0aGVybW9yZSwgd2hhdCBuZnNfZ2V0YXR0cigpIGRvZXMgY2Fu
IGJlIGNvbnRyb2xsZWQgYXMgZm9sbG93czoNCj4gDQo+ICAoMSkgSWYgQVRfRk9SQ0VfQVRUUl9T
WU5DIGlzIGluZGljYXRlZCwgb3IgbXRpbWUsIGN0aW1lIG9yIGRhdGFfdmVyc2lvbiAoTkZTdjQN
Cj4gICAgICBvbmx5KSBhcmUgcmVxdWVzdGVkIHRoZW4gdGhlIG91dHN0YW5kaW5nIHdyaXRlcyB3
aWxsIGJlIHdyaXR0ZW4gdG8gdGhlDQo+ICAgICAgc2VydmVyIGZpcnN0Lg0KPiANCj4gICgyKSBU
aGUgaW5vZGUncyBhdHRyaWJ1dGVzIG1heSBiZSBzeW5jaHJvbmlzZWQgd2l0aCB0aGUgc2VydmVy
Og0KPiANCj4gICAgICAoYSkgSWYgQVRfRk9SQ0VfQVRUUl9TWU5DIGlzIGluZGljYXRlZCBvciBp
ZiBhdGltZSBpcyByZXF1ZXN0ZWQgKGFuZCBhdGltZQ0KPiAgICAgIAkgdXBkYXRpbmcgaXMgbm90
IHN1cHByZXNzZWQgYnkgYSBtb3VudCBmbGFnKSB0aGVuIHRoZSBhdHRyaWJ1dGVzIHdpbGwNCj4g
ICAgICAJIGJlIHJlcmVhZCB1bmNvbmRpdGlvbmFsbHkuDQo+IA0KPiAgICAgIChiKSBJZiB0aGUg
ZGF0YSB2ZXJzaW9uIG9yIGFueSBvZiBiYXNpYyBzdGF0cyBhcmUgcmVxdWVzdGVkIHRoZW4gdGhl
DQo+ICAgICAgCSBhdHRyaWJ1dGVzIHdpbGwgYmUgcmVyZWFkIGlmIHRoZSBjYWNoZWQgYXR0cmli
dXRlcyBoYXZlIGV4cGlyZWQuDQo+IA0KPiAgICAgIChjKSBPdGhlcndpc2UgdGhlIGNhY2hlZCBh
dHRyaWJ1dGVzIHdpbGwgYmUgdXNlZCAtIGV2ZW4gaWYgZXhwaXJlZCAtDQo+ICAgICAgCSB3aXRo
b3V0IHJlZmVyZW5jZSB0byB0aGUgc2VydmVyLg0KDQpIbW0uLi4gQXMgZmFyIGFzIEkgY2FuIHNl
ZSB5b3UgYXJlIHN0aWxsIGRvaW5nIGFuIG5mc19yZXZhbGlkYXRlX2lub2RlKCkNCmluIHRoZSBu
b24tZm9yY2VkIGNhc2UuIFRoYXQgd2lsbCBjYXVzZSBleHBpcmVkIGF0dHJpYnV0ZXMgdG8gYmUN
CnJldHJpZXZlZCBmcm9tIHRoZSBzZXJ2ZXIuDQoNCj4gU2lnbmVkLW9mZi1ieTogRGF2aWQgSG93
ZWxscyA8ZGhvd2VsbHNAcmVkaGF0LmNvbT4NCj4gLS0tDQo+IA0KPiAgZnMvbmZzL2lub2RlLmMg
fCAgIDQ5ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0N
Cj4gIGZzL25mcy9zdXBlci5jIHwgICAgMSArDQo+ICAyIGZpbGVzIGNoYW5nZWQsIDM4IGluc2Vy
dGlvbnMoKyksIDEyIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2ZzL25mcy9pbm9k
ZS5jIGIvZnMvbmZzL2lub2RlLmMNCj4gaW5kZXggZThiYmZhNS4uNDYwZmNmMyAxMDA2NDQNCj4g
LS0tIGEvZnMvbmZzL2lub2RlLmMNCj4gKysrIGIvZnMvbmZzL2lub2RlLmMNCj4gQEAgLTUwOSwx
MSArNTA5LDE4IEBAIHZvaWQgbmZzX3NldGF0dHJfdXBkYXRlX2lub2RlKHN0cnVjdCBpbm9kZSAq
aW5vZGUsIHN0cnVjdCBpYXR0ciAqYXR0cikNCj4gIGludCBuZnNfZ2V0YXR0cihzdHJ1Y3QgdmZz
bW91bnQgKm1udCwgc3RydWN0IGRlbnRyeSAqZGVudHJ5LCBzdHJ1Y3Qga3N0YXQgKnN0YXQpDQo+
ICB7DQo+ICAJc3RydWN0IGlub2RlICppbm9kZSA9IGRlbnRyeS0+ZF9pbm9kZTsNCj4gKwl1bnNp
Z25lZCBmb3JjZSA9IHN0YXQtPnF1ZXJ5X2ZsYWdzICYgQVRfRk9SQ0VfQVRUUl9TWU5DOw0KPiAg
CWludCBuZWVkX2F0aW1lID0gTkZTX0koaW5vZGUpLT5jYWNoZV92YWxpZGl0eSAmIE5GU19JTk9f
SU5WQUxJRF9BVElNRTsNCj4gIAlpbnQgZXJyOw0KPiAgDQo+IC0JLyogRmx1c2ggb3V0IHdyaXRl
cyB0byB0aGUgc2VydmVyIGluIG9yZGVyIHRvIHVwZGF0ZSBjL210aW1lLiAgKi8NCj4gLQlpZiAo
U19JU1JFRyhpbm9kZS0+aV9tb2RlKSkgew0KPiArCWlmIChORlNfU0VSVkVSKGlub2RlKS0+bmZz
X2NsaWVudC0+cnBjX29wcy0+dmVyc2lvbiA8IDQpDQo+ICsJCXN0YXQtPnJlcXVlc3RfbWFzayAm
PSB+WFNUQVRfVkVSU0lPTjsNCj4gKw0KPiArCS8qIEZsdXNoIG91dCB3cml0ZXMgdG8gdGhlIHNl
cnZlciBpbiBvcmRlciB0byB1cGRhdGUgYy9tdGltZQ0KPiArCSAqIG9yIGRhdGEgdmVyc2lvbiBp
ZiB0aGUgdXNlciB3YW50cyB0aGVtICovDQo+ICsJaWYgKChmb3JjZSB8fCAoc3RhdC0+cmVxdWVz
dF9tYXNrICYNCj4gKwkJICAgICAgIChYU1RBVF9NVElNRSB8IFhTVEFUX0NUSU1FIHwgWFNUQVRf
VkVSU0lPTikpKSAmJg0KPiArCSAgICBTX0lTUkVHKGlub2RlLT5pX21vZGUpKSB7DQo+ICAJCWVy
ciA9IGZpbGVtYXBfd3JpdGVfYW5kX3dhaXQoaW5vZGUtPmlfbWFwcGluZyk7DQoNCldlIGNhbiBn
ZXQgcmlkIG9mIHRoZSBmaWxlbWFwX3dyaXRlX2FuZF93YWl0KCkgaWYgdGhlIGNhbGxlciBhbGxv
d3MgdXMNCnRvIGFwcHJveGltYXRlIG0vY3RpbWUgdmFsdWVzLiBUaGF0IHdvdWxkIGdpdmUgYSBt
YWpvciBzcGVlZC11cCBmb3IgbW9zdA0Kc3RhdCgpIHdvcmtsb2Fkcy4NCg0KPiAgCQlpZiAoZXJy
KQ0KPiAgCQkJZ290byBvdXQ7DQo+IEBAIC01MjgsMTggKzUzNSwzNiBAQCBpbnQgbmZzX2dldGF0
dHIoc3RydWN0IHZmc21vdW50ICptbnQsIHN0cnVjdCBkZW50cnkgKmRlbnRyeSwgc3RydWN0IGtz
dGF0ICpzdGF0KQ0KPiAgCSAqICAtIE5GUyBuZXZlciBzZXRzIE1TX05PQVRJTUUgb3IgTVNfTk9E
SVJBVElNRSBzbyB0aGVyZSBpcw0KPiAgCSAqICAgIG5vIHBvaW50IGluIGNoZWNraW5nIHRob3Nl
Lg0KPiAgCSAqLw0KPiAtIAlpZiAoKG1udC0+bW50X2ZsYWdzICYgTU5UX05PQVRJTUUpIHx8DQo+
IC0gCSAgICAoKG1udC0+bW50X2ZsYWdzICYgTU5UX05PRElSQVRJTUUpICYmIFNfSVNESVIoaW5v
ZGUtPmlfbW9kZSkpKQ0KPiArCWlmIChtbnQtPm1udF9mbGFncyAmIE1OVF9OT0FUSU1FIHx8DQo+
ICsJICAgIChtbnQtPm1udF9mbGFncyAmIE1OVF9OT0RJUkFUSU1FICYmIFNfSVNESVIoaW5vZGUt
PmlfbW9kZSkpKSB7DQo+ICsJCXN0YXQtPmlvY19mbGFncyB8PSBGU19OT0FUSU1FX0ZMOw0KPiAr
CQluZWVkX2F0aW1lID0gMDsNCj4gKwl9IGVsc2UgaWYgKCEoc3RhdC0+cmVxdWVzdF9tYXNrICYg
WFNUQVRfQVRJTUUpKSB7DQo+ICAJCW5lZWRfYXRpbWUgPSAwOw0KPiArCX0NCj4gIA0KPiAtCWlm
IChuZWVkX2F0aW1lKQ0KPiAtCQllcnIgPSBfX25mc19yZXZhbGlkYXRlX2lub2RlKE5GU19TRVJW
RVIoaW5vZGUpLCBpbm9kZSk7DQo+IC0JZWxzZQ0KPiAtCQllcnIgPSBuZnNfcmV2YWxpZGF0ZV9p
bm9kZShORlNfU0VSVkVSKGlub2RlKSwgaW5vZGUpOw0KPiAtCWlmICghZXJyKSB7DQo+IC0JCWdl
bmVyaWNfZmlsbGF0dHIoaW5vZGUsIHN0YXQpOw0KPiAtCQlzdGF0LT5pbm8gPSBuZnNfY29tcGF0
X3VzZXJfaW5vNjQoTkZTX0ZJTEVJRChpbm9kZSkpOw0KPiArCWlmIChmb3JjZSB8fCBzdGF0LT5y
ZXF1ZXN0X21hc2sgJiAoWFNUQVRfQkFTSUNfU1RBVFMgfCBYU1RBVF9WRVJTSU9OKSkgew0KPiAr
CQlpZiAoZm9yY2UgfHwgbmVlZF9hdGltZSkNCj4gKwkJCWVyciA9IF9fbmZzX3JldmFsaWRhdGVf
aW5vZGUoTkZTX1NFUlZFUihpbm9kZSksIGlub2RlKTsNCj4gKwkJZWxzZQ0KPiArCQkJZXJyID0g
bmZzX3JldmFsaWRhdGVfaW5vZGUoTkZTX1NFUlZFUihpbm9kZSksIGlub2RlKTsNCj4gKwkJaWYg
KGVycikNCj4gKwkJCWdvdG8gb3V0Ow0KPiAgCX0NCj4gKw0KPiArCWdlbmVyaWNfZmlsbGF0dHIo
aW5vZGUsIHN0YXQpOw0KPiArCXN0YXQtPmlubyA9IG5mc19jb21wYXRfdXNlcl9pbm82NChORlNf
RklMRUlEKGlub2RlKSk7DQo+ICsNCj4gKwlpZiAoc3RhdC0+cmVxdWVzdF9tYXNrICYgWFNUQVRf
VkVSU0lPTikgew0KPiArCQlzdGF0LT52ZXJzaW9uID0gaW5vZGUtPmlfdmVyc2lvbjsNCj4gKwkJ
c3RhdC0+cmVzdWx0X21hc2sgfD0gWFNUQVRfVkVSU0lPTjsNCj4gKwl9DQo+ICsNCj4gKwlpZiAo
SVNfQVVUT01PVU5UKGlub2RlKSkNCj4gKwkJc3RhdC0+aW5mb3JtYXRpb24gfD0gWFNUQVRfSU5G
T19GQUJSSUNBVEVEOw0KPiArDQo+ICsJc3RhdC0+aW5mb3JtYXRpb24gfD0gWFNUQVRfSU5GT19S
RU1PVEU7DQo+ICsNCj4gIG91dDoNCj4gIAlyZXR1cm4gZXJyOw0KPiAgfQ0KPiBAQCAtODUyLDcg
Kzg3Nyw3IEBAIGludCBuZnNfcmV2YWxpZGF0ZV9pbm9kZShzdHJ1Y3QgbmZzX3NlcnZlciAqc2Vy
dmVyLCBzdHJ1Y3QgaW5vZGUgKmlub2RlKQ0KPiAgc3RhdGljIGludCBuZnNfaW52YWxpZGF0ZV9t
YXBwaW5nKHN0cnVjdCBpbm9kZSAqaW5vZGUsIHN0cnVjdCBhZGRyZXNzX3NwYWNlICptYXBwaW5n
KQ0KPiAgew0KPiAgCXN0cnVjdCBuZnNfaW5vZGUgKm5mc2kgPSBORlNfSShpbm9kZSk7DQo+IC0J
DQo+ICsNCj4gIAlpZiAobWFwcGluZy0+bnJwYWdlcyAhPSAwKSB7DQo+ICAJCWludCByZXQgPSBp
bnZhbGlkYXRlX2lub2RlX3BhZ2VzMihtYXBwaW5nKTsNCj4gIAkJaWYgKHJldCA8IDApDQo+IGRp
ZmYgLS1naXQgYS9mcy9uZnMvc3VwZXIuYyBiL2ZzL25mcy9zdXBlci5jDQo+IGluZGV4IDM3NDEy
ZjcuLmZhYTY1MmMgMTAwNjQ0DQo+IC0tLSBhL2ZzL25mcy9zdXBlci5jDQo+ICsrKyBiL2ZzL25m
cy9zdXBlci5jDQo+IEBAIC0yMjIyLDYgKzIyMjIsNyBAQCBzdGF0aWMgaW50IG5mc19zZXRfc3Vw
ZXIoc3RydWN0IHN1cGVyX2Jsb2NrICpzLCB2b2lkICpkYXRhKQ0KPiAgCXJldCA9IHNldF9hbm9u
X3N1cGVyKHMsIHNlcnZlcik7DQo+ICAJaWYgKHJldCA9PSAwKQ0KPiAgCQlzZXJ2ZXItPnNfZGV2
ID0gcy0+c19kZXY7DQo+ICsJbWVtY3B5KCZzLT5zX3ZvbHVtZV9pZCwgJnNlcnZlci0+ZnNpZCwg
c2l6ZW9mKHMtPnNfdm9sdW1lX2lkKSk7DQo+ICAJcmV0dXJuIHJldDsNCj4gIH0NCj4gIA0KPiAN
Cj4gLS0NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVu
c3Vic2NyaWJlIGxpbnV4LW5mcyIgaW4NCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9y
ZG9tb0B2Z2VyLmtlcm5lbC5vcmcNCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3Zn
ZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0
DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RA
bmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg0K

2012-04-26 14:04:59

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Paul Eggert <[email protected]> wrote:

> On 04/19/2012 09:32 AM, Roland McGrath wrote:
> > I have no comment on the functionality. But "xstat" is probably a poor
> > choice of name.
>
> In AIX 7.1 the (similar) function is called statxat instead of xstat.
> The API isn't exactly the same, but it's the same basic idea.
> Might be worth looking at, not merely to see whether the API
> should be the same, but also to borrow good ideas even if not.
>
> http://pic.dhe.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.basetechref/doc/basetrf2/statx.htm

Interesting. I wasn't intending to provide both statx() and statxat()
variants, just the latter, in which case I'd've though that -at suffix is
redundant.

I note that they split their time fields into separate seconds and ns fields,
presumably for better packing.

David

2012-04-26 17:03:08

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
<[email protected]> wrote:
> On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
>> <[email protected]> wrote:
>> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
>> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <[email protected]> wrote:
>> >> > Steve French <[email protected]> wrote:
>> >> >
>> >> >> Would it be better to make the stable vs volatile inode number an attribute
>> >> >> of the volume ?or something returned by the proposed xstat?
>> >> >
>> >> > I'm not sure what you mean by a stable vs a volatile inode number.
>> >>
>> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
>> >> unique identifier, but in the case of CIFS some old servers don't support the
>> >> calls which return inode numbers (or don't return them for all file system
>> >> types, Windows FAT?) so in these cases cifs has to create inode
>> >> numbers on the fly
>> >> on the client. ? inode numbers created on the client are not "stable" they
>> >> can change on unmount/remount (which can cause problems for backup
>> >> applications).
>> >>
>> >> Similarly NFSv4 does not require that servers always return stable inode numbers
>> >> (that will never change) and introduced a concept of "volatile file handle."
>> >> We have run into this in two cases (there are probably more) -
>> >> Specialized NFS servers
>> >> for HPC which deal with lots of transient inodes, and second those for servers
>> >> which base there inode number on path (Windows NFS?). ?See
>> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
>> >> or the NFSv4 RFC.
>> >>
>> >> Basically the question is whether it is worth reporting a flag on the
>> >> call which returns
>> >> the inode number to indicate that the inode number is "stable" (would not change
>> >> on reboot or reconnection) or "volatile." ? ?Since the majority of NFS
>> >> and SMB2 servers
>> >> can return stable inode numbers, I don't feel strongly about the need
>> >> for an indicator
>> >> of "stable" vs. "volatile" but I mention it because backup and
>> >> migration applications
>> >> mention this (if inode numbers are volatile, they may have to check
>> >> for hardlinks differently
>> >> for example)
>> >
>> > I don't understand. If the filesystem doesn't support real inode
>> > numbers, then why report them at all? What use would an application have
>> > for an inode number that can't be used to identify hard linked files?
>>
>> Well ... you have to have an inode number on the Linux client side even if
>> the server doesn't report them (or has a bug and reports duplicates).
>> If you can't tell hardlinked files apart fix the server (but in the
>> cases where the file systems has this problem the server doesn't usually
>> support hardlinks either).
>>
>> If the server's file system internal structures don't support real inode
>> numbers (such as FAT or a ramdisk) then it either has to make them
>> up based on something like path name or some other attribute of the
>> file on disk.
>>
>> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009
>> query file info is used to query_file_internal_info (the inode number) but
>> what if the server can not report inode numbers (due to a bug) in
>> all cases.
>
> Right, but none of this explains why we need to report these bogus inode
> numbers to the application in the xstat() reply.

the question is whether the application (backup) would need to know
that the inode numbers are bogus and from my conversations with
guys writing backup software it seems that such data is useful to them.

--
Thanks,

Steve

2012-04-26 21:58:39

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Myklebust, Trond <[email protected]> wrote:

> You are still not explaining why they need to know the values at all? If
> the values are bogus, then don't return them, and don't set the flag
> that says they are being returned.

What if the xstat() and struct xstat eventually becomes what userspace uses as
stat() (as a wrapper) and struct stat (if such a thing is possible with glibc
versioning)? Do older programs that think they're using stat() and don't know
about the extra fields available expect to see a useful value in st_ino?

David

2012-04-27 13:13:11

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Fri, Apr 27, 2012 at 10:39:05AM +0100, David Howells wrote:
> Dave Chinner <[email protected]> wrote:
>
> > 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?
>
> I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly
> which flags you're talking about. The question, though, is what will actually
> make use of these flags? Will it just be XFS tools or are they something that
> a GUI might make use of?

Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined
at the bottom of the file.

Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly
generic - they are for indicating that files are to be avoided for defrag or
backup purposes, the prealloc bit indicates that fallocate has been
used to reserve space on the inode (finding files that space can be
punched out of safely), and so on.

Currently these things are queried and manipulated by ioctls
(XFS_IOC_FSX[GS]ETATTR) along with extent size hints, project
quotas, etc. but I think there's some wider use for many of the
flags, which is why I was asking is there's any thought to this sort
of flag being exposed by the VFS.

Historically the flags exposed by the VFS are those used by extN - I
see little reason why we should favour one filesystem's flags over
any others in an extended stat interface if they are generically
useful....

> Either you can add some of them to the ioc flags (which may be impractical, I
> grant you) or we'd have to add an arbitrary fs-type specific field and specify
> the host fs (the provision of which might not be a bad idea in and of itself)
> to tell userspace how to interpret them.

Well, that's the complexity, isn't it. I have no good answer to
that...

> > 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...
>
> Yeah... Not representable by one number. You'd have to unset a flag to say
> you were providing this information.
>
> However, providing a whole bunch of hints about I/O characteristics is probably
> beyond this syscall - especially if it isn't constant over the length of a
> file. That's specialist knowledge that most applications don't need to know.
> Having a generic way to retrieve it, though, may be a good idea.

We're continually talking about applications giving us usage hints
on what IO they are going to do so the storage can optimise the IO.
IO is still a GIGO problem, though, and the idea of geometry hints is to enable
us to tell the application to do well formed IO. i.e. less garbage.

XFS has ioctls to expose filesystem geometry, optimal IO sizes, the
alignment limits for direct IO, etc, and they are very useful to
applications that care about high performance IO. A lot of this can
be distilled down to a simple set of geometries, and generally
speaking they don't change mid way through a file....

> OTOH, there's plenty of uncommitted space, so if we can condense the hints down
> to something small, we could perhaps add it later - but from your paragraph
> above, it doesn't sound like it'll be small.

Allocation block size, minimum sane IO size (to avoid page cache RMW
cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit),
optimal IO size for bandwidth (e.g. stripe width). I don't think
there's much more than that which will be really usable by
applications.

> > 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....
>
> Is this an XFS only thing? If so, can it be generalised?

Right now it is, but there's ben patches in the past to introduce
project quotas to ext4. That didn't go far because it was done in a
way that was semantically different to XFS (for no reason that I
could understand) and nobody wanted two different sets of semantics
for the "same" feature. The most common use of project quotas is to
implement sub-tree quotas, which is probably of more interest to
btrfs folks as it is an exact match for per-subvolume quotas.

So, yes, I do see it as something generically useful - it's a
feature that a lot of people use XFS specifically for....

Cheers,

Dave.
--
Dave Chinner
[email protected]

2012-04-27 09:20:05

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Andreas Dilger <[email protected]> wrote:

> > However, since there is a remote file ID, we could add an
> > XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr holding this.
>
> It is a bit strange that the kernel would return a flag that was not
> requested, but not fatal.

On the other hand, if it costs the kernel nothing to generate this indicator...

For network filesystems, for instance, you might know that there is some other
file ID because of the way the fs is specified.

I was thinking that many of the fields will be given values, even if you don't
ask for them, because the values (or approximations thereof) are present in
memory already.

David

2012-04-26 14:23:52

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote:
> J. Bruce Fields <[email protected]> wrote:
>
> > > (11) Include granularity fields in the time data to indicate the
> > > granularity of each of the times (NFSv4 time_delta) [Steve French].
> >
> > It looks like you're including this with *each* time? But surely
> > there's no filesystem with different granularity (say) for ctime than
> > for mtime.
>
> I put it in each time struct to use up the hole there. I could, I suppose,
> split tv_sec from tv_nsec to get rid of the holes and then put the granularity
> separately. That means that someone who wanted both the tv_sec and tv_nsec
> would have to fish them out separately, but that's probably okay.
>
> I could even make the granularity bigger then, to allow for the possibility of
> having a granularity >4s, but I don't know of anywhere that requires a gran >2.
>
> > Also, nfsd will want only one time_delta, not one for each time.
>
> time_delta? Is that the same as granularity?

Right, sorry, that's just the NFS word for the same thing.

So my whine here is just that most callers only want to know one number
and we're giving them three. Whatever, they can just pick one. It
feels a little ugly, but feel free to ignore my nitpicking....

(Though as Steve French asked: could we add this to statfs (or something
similar) instead?)

>
> > Note also we need to document carefully what this means: I think it
> > should be the granularity that the filesystem is capable of
> > representing, but people are sometimes surprised to find out that the
> > actual time source is usually more coarse-grained than that.
>
> Yeah, but the latter is something you may not be able to determine, and may
> indeed change over time (say someone updates the server kernel to one with a
> more fine-grained software clock). Also, for a network fs, it may depend on
> the client that happened to set that time last.

Yep, agreed, the granularity should be what the filesystem can store, we
should just make sure that statement makes it into any eventual man
pages or other documentation, since it does seem to surprise people.

--b.

2012-04-19 15:19:57

[permalink] [raw]

Subject: Re: [PATCH 5/6] xstat: CIFS: Return extended attributes

For some of our users this would help A LOT.

Interesting ... just had discussions yesterday with some guys trying
to migrate to Linux and another set trying to backup Windows/NetApp
from Linux.

Some things they brought up that they needed (beyond what we already
have wth the cifs acl and SID and "dos attributes" xattrs, which is
even more useful now with the backup intent cifs mount flag) included:
- how do they tell if the inode number for a file was manufactured on
the client, or whether we were able to use the server file's inode
number ("UniqueId")
- how to get birth time (creation time)
- how to tell if file is "offline" (HSM)
- And is there a way to return the other less common cifs attributes
(e.g. "reparse")

Dave's patch seems to address all of that. Samba server stuffs most
of this in an ndr encoded xattr blob which isn't much good for kernel
code to use, and I really prefer Dave's approach. Without this, I
would need to add another cifs specific ioctl, but since there is
significant overlap between some of these and ntfs, vfat, nfs etc. I
like the xstat idea better.

On Thu, Apr 19, 2012 at 9:07 AM, David Howells <[email protected]> wrote:
> Return extended attributes from the CIFS filesystem. ?This includes the
> following:
>
> ?(1) Return the file creation time as btime. ?We assume that the creation time
> ? ? won't change over the life of the inode.
>
> ?(2) Set XSTAT_INFO_AUTOMOUNT on referral/submount directories.
>
> ?(3) Unset XSTAT_INO if we made up the inode number and didn't get it from the
> ? ? server.
>
> ?(4) Unset XSTAT_[UG]ID if we are either returning values passed to mount
> ? ? and/or the server doesn't return them.
>
> ?(5) Map various Windows file attributes to FS_xxx_FL flags in st_ioc_flags
> ? ? and XSTAT_INFO_xxx flags in st_information, fetching them from the server
> ? ? if we don't have them yet or don't have a current copy.
>
> ? ? Possibly things like Hidden, System and Archive should be FS_xxx_FL flags
> ? ? rather than XSTAT_INFO_xxx flags and st_ioc_flags should be expanded to
> ? ? 64 bits.
>
> ?(6) Set XSTAT_INFO_REMOTE on all files fetched by CIFS.
>
> ?(7) Set XSTAT_INFO_NONSYSTEM_OWNERSHIP on all files as they all have Windows
> ? ? ownership details too.
>
> ?(8) Set XSTAT_INFO_HAS_ACL if CONFIG_CIFS_ACL=y as Windows ACLs are available
> ? ? on the object.
>
> Furthermore, what cifs_getattr() does can be controlled as follows:
>
> ?(1) If AT_FORCE_ATTR_SYNC is indicated, or if the inode flags or creation time
> ? ? are requested but not yet collected, then the attributes will be reread
> ? ? unconditionally.
>
> ?(2) If the basic stats are requested or if the inode flags are requested and
> ? ? have been collected previously, then the attributes will be reread if out
> ? ? of date.
>
> ?(3) Otherwise the cached attributes will be used - even if expired - without
> ? ? reference to the server.
>
> Note that cifs_revalidate_dentry() will issue an extra operation to get the
> FILE_ALL_INFO in addition to the FILE_UNIX_BASIC_INFO if it needs to collect
> creation time and attributes on behalf of cifs_getattr().
>
> [NOTE: THIS PATCH IS UNTESTED!]
>
> Signed-off-by: David Howells <[email protected]>
> ---
>
> ?fs/cifs/cifsfs.h ? | ? ?4 +-
> ?fs/cifs/cifsglob.h | ? 16 +++++--
> ?fs/cifs/dir.c ? ? ?| ? ?2 -
> ?fs/cifs/inode.c ? ?| ?120 +++++++++++++++++++++++++++++++++++++++++++++-------
> ?4 files changed, 118 insertions(+), 24 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h
> index d1389bb..021e327 100644
> --- a/fs/cifs/cifsfs.h
> +++ b/fs/cifs/cifsfs.h
> @@ -56,9 +56,9 @@ extern int cifs_rmdir(struct inode *, struct dentry *);
> ?extern int cifs_rename(struct inode *, struct dentry *, struct inode *,
> ? ? ? ? ? ? ? ? ? ? ? struct dentry *);
> ?extern int cifs_revalidate_file_attr(struct file *filp);
> -extern int cifs_revalidate_dentry_attr(struct dentry *);
> +extern int cifs_revalidate_dentry_attr(struct dentry *, bool, bool);
> ?extern int cifs_revalidate_file(struct file *filp);
> -extern int cifs_revalidate_dentry(struct dentry *);
> +extern int cifs_revalidate_dentry(struct dentry *, bool, bool);
> ?extern int cifs_invalidate_mapping(struct inode *inode);
> ?extern int cifs_getattr(struct vfsmount *, struct dentry *, struct kstat *);
> ?extern int cifs_setattr(struct dentry *, struct iattr *);
> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> index 4ff6313..d3567da 100644
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -621,11 +621,15 @@ struct cifsInodeInfo {
> ? ? ? ?/* BB add in lists for dirty pages i.e. write caching info for oplock */
> ? ? ? ?struct list_head openFileList;
> ? ? ? ?__u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */
> - ? ? ? bool clientCanCacheRead; ? ? ? ?/* read oplock */
> - ? ? ? bool clientCanCacheAll; ? ? ? ? /* read and writebehind oplock */
> - ? ? ? bool delete_pending; ? ? ? ? ? ?/* DELETE_ON_CLOSE is set */
> - ? ? ? bool invalid_mapping; ? ? ? ? ? /* pagecache is invalid */
> + ? ? ? bool clientCanCacheRead:1; ? ? ?/* read oplock */
> + ? ? ? bool clientCanCacheAll:1; ? ? ? /* read and writebehind oplock */
> + ? ? ? bool delete_pending:1; ? ? ? ? ?/* DELETE_ON_CLOSE is set */
> + ? ? ? bool invalid_mapping:1; ? ? ? ? /* pagecache is invalid */
> + ? ? ? bool btime_valid:1; ? ? ? ? ? ? /* stored creation time is valid */
> + ? ? ? bool uid_faked:1; ? ? ? ? ? ? ? /* true if i_uid is faked */
> + ? ? ? bool gid_faked:1; ? ? ? ? ? ? ? /* true if i_gid is faked */
> ? ? ? ?unsigned long time; ? ? ? ? ? ? /* jiffies of last update of inode */
> + ? ? ? struct timespec btime; ? ? ? ? ?/* creation time */
> ? ? ? ?u64 ?server_eof; ? ? ? ? ? ? ? ?/* current file size on server -- protected by i_lock */
> ? ? ? ?u64 ?uniqueid; ? ? ? ? ? ? ? ? ?/* server inode number */
> ? ? ? ?u64 ?createtime; ? ? ? ? ? ? ? ?/* creation time on server */
> @@ -833,6 +837,9 @@ struct dfs_info3_param {
> ?#define CIFS_FATTR_DELETE_PENDING ? ? ?0x2
> ?#define CIFS_FATTR_NEED_REVAL ? ? ? ? ?0x4
> ?#define CIFS_FATTR_INO_COLLISION ? ? ? 0x8
> +#define CIFS_FATTR_WINATTRS_VALID ? ? ?0x10 ? ?/* T if cf_btime and cf_cifsattrs valid */
> +#define CIFS_FATTR_UID_FAKED ? ? ? ? ? 0x20 ? ?/* T if cf_uid is faked */
> +#define CIFS_FATTR_GID_FAKED ? ? ? ? ? 0x40 ? ?/* T if cf_gid is faked */
>
> ?struct cifs_fattr {
> ? ? ? ?u32 ? ? ? ? ? ? cf_flags;
> @@ -850,6 +857,7 @@ struct cifs_fattr {
> ? ? ? ?struct timespec cf_atime;
> ? ? ? ?struct timespec cf_mtime;
> ? ? ? ?struct timespec cf_ctime;
> + ? ? ? struct timespec cf_btime;
> ?};
>
> ?static inline void free_dfs_info_param(struct dfs_info3_param *param)
> diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
> index d172c8e..d9e03ae 100644
> --- a/fs/cifs/dir.c
> +++ b/fs/cifs/dir.c
> @@ -664,7 +664,7 @@ cifs_d_revalidate(struct dentry *direntry, struct nameidata *nd)
> ? ? ? ? ? ? ? ?return -ECHILD;
>
> ? ? ? ?if (direntry->d_inode) {
> - ? ? ? ? ? ? ? if (cifs_revalidate_dentry(direntry))
> + ? ? ? ? ? ? ? if (cifs_revalidate_dentry(direntry, false, false))
> ? ? ? ? ? ? ? ? ? ? ? ?return 0;
> ? ? ? ? ? ? ? ?else {
> ? ? ? ? ? ? ? ? ? ? ? ?/*
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index 745da3d..662d5ce 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -135,13 +135,21 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr)
> ? ? ? ?set_nlink(inode, fattr->cf_nlink);
> ? ? ? ?inode->i_uid = fattr->cf_uid;
> ? ? ? ?inode->i_gid = fattr->cf_gid;
> + ? ? ? if (fattr->cf_flags & CIFS_FATTR_UID_FAKED)
> + ? ? ? ? ? ? ? cifs_i->uid_faked = true;
> + ? ? ? if (fattr->cf_flags & CIFS_FATTR_GID_FAKED)
> + ? ? ? ? ? ? ? cifs_i->gid_faked = true;
>
> ? ? ? ?/* if dynperm is set, don't clobber existing mode */
> ? ? ? ?if (inode->i_state & I_NEW ||
> ? ? ? ? ? ?!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_DYNPERM))
> ? ? ? ? ? ? ? ?inode->i_mode = fattr->cf_mode;
>
> - ? ? ? cifs_i->cifsAttrs = fattr->cf_cifsattrs;
> + ? ? ? if (fattr->cf_flags & CIFS_FATTR_WINATTRS_VALID) {
> + ? ? ? ? ? ? ? cifs_i->cifsAttrs = fattr->cf_cifsattrs;
> + ? ? ? ? ? ? ? cifs_i->btime = fattr->cf_btime;
> + ? ? ? ? ? ? ? cifs_i->btime_valid = true;
> + ? ? ? }
>
> ? ? ? ?if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)
> ? ? ? ? ? ? ? ?cifs_i->time = 0;
> @@ -248,15 +256,19 @@ cifs_unix_basic_to_fattr(struct cifs_fattr *fattr, FILE_UNIX_BASIC_INFO *info,
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?}
>
> - ? ? ? if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID)
> + ? ? ? if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID) {
> ? ? ? ? ? ? ? ?fattr->cf_uid = cifs_sb->mnt_uid;
> - ? ? ? else
> + ? ? ? ? ? ? ? fattr->cf_flags |= CIFS_FATTR_UID_FAKED;
> + ? ? ? } else {
> ? ? ? ? ? ? ? ?fattr->cf_uid = le64_to_cpu(info->Uid);
> + ? ? ? }
>
> - ? ? ? if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)
> + ? ? ? if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID) {
> ? ? ? ? ? ? ? ?fattr->cf_gid = cifs_sb->mnt_gid;
> - ? ? ? else
> + ? ? ? ? ? ? ? fattr->cf_flags |= CIFS_FATTR_GID_FAKED;
> + ? ? ? } else {
> ? ? ? ? ? ? ? ?fattr->cf_gid = le64_to_cpu(info->Gid);
> + ? ? ? }
>
> ? ? ? ?fattr->cf_nlink = le64_to_cpu(info->Nlinks);
> ?}
> @@ -283,7 +295,8 @@ cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb)
> ? ? ? ?fattr->cf_ctime = CURRENT_TIME;
> ? ? ? ?fattr->cf_mtime = CURRENT_TIME;
> ? ? ? ?fattr->cf_nlink = 2;
> - ? ? ? fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL;
> + ? ? ? fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL |
> + ? ? ? ? ? ? ? CIFS_FATTR_UID_FAKED | CIFS_FATTR_GID_FAKED;
> ?}
>
> ?int cifs_get_file_info_unix(struct file *filp)
> @@ -510,6 +523,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,
> ? ? ? ?struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
>
> ? ? ? ?memset(fattr, 0, sizeof(*fattr));
> + ? ? ? fattr->cf_flags = CIFS_FATTR_WINATTRS_VALID;
> ? ? ? ?fattr->cf_cifsattrs = le32_to_cpu(info->Attributes);
> ? ? ? ?if (info->DeletePending)
> ? ? ? ? ? ? ? ?fattr->cf_flags |= CIFS_FATTR_DELETE_PENDING;
> @@ -521,6 +535,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,
>
> ? ? ? ?fattr->cf_ctime = cifs_NTtimeToUnix(info->ChangeTime);
> ? ? ? ?fattr->cf_mtime = cifs_NTtimeToUnix(info->LastWriteTime);
> + ? ? ? fattr->cf_btime = cifs_NTtimeToUnix(info->CreationTime);
>
> ? ? ? ?if (adjust_tz) {
> ? ? ? ? ? ? ? ?fattr->cf_ctime.tv_sec += tcon->ses->server->timeAdj;
> @@ -1724,7 +1739,8 @@ int cifs_revalidate_file_attr(struct file *filp)
> ? ? ? ?return rc;
> ?}
>
> -int cifs_revalidate_dentry_attr(struct dentry *dentry)
> +int cifs_revalidate_dentry_attr(struct dentry *dentry,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bool want_extra_bits, bool force)
> ?{
> ? ? ? ?int xid;
> ? ? ? ?int rc = 0;
> @@ -1735,7 +1751,7 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry)
> ? ? ? ?if (inode == NULL)
> ? ? ? ? ? ? ? ?return -ENOENT;
>
> - ? ? ? if (!cifs_inode_needs_reval(inode))
> + ? ? ? if (!force && !cifs_inode_needs_reval(inode))
> ? ? ? ? ? ? ? ?return rc;
>
> ? ? ? ?xid = GetXid();
> @@ -1752,9 +1768,12 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry)
> ? ? ? ? ? ? ? ? "%ld jiffies %ld", full_path, inode, inode->i_count.counter,
> ? ? ? ? ? ? ? ? dentry, dentry->d_time, jiffies);
>
> - ? ? ? if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext)
> + ? ? ? if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) {
> ? ? ? ? ? ? ? ?rc = cifs_get_inode_info_unix(&inode, full_path, sb, xid);
> - ? ? ? else
> + ? ? ? ? ? ? ? if (rc != 0)
> + ? ? ? ? ? ? ? ? ? ? ? goto out;
> + ? ? ? }
> + ? ? ? if (!cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext || want_extra_bits)
> ? ? ? ? ? ? ? ?rc = cifs_get_inode_info(&inode, full_path, NULL, sb,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? xid, NULL);
>
> @@ -1779,12 +1798,13 @@ int cifs_revalidate_file(struct file *filp)
> ?}
>
> ?/* revalidate a dentry's inode attributes */
> -int cifs_revalidate_dentry(struct dentry *dentry)
> +int cifs_revalidate_dentry(struct dentry *dentry,
> + ? ? ? ? ? ? ? ? ? ? ? ? ?bool want_extra_bits, bool force)
> ?{
> ? ? ? ?int rc;
> ? ? ? ?struct inode *inode = dentry->d_inode;
>
> - ? ? ? rc = cifs_revalidate_dentry_attr(dentry);
> + ? ? ? rc = cifs_revalidate_dentry_attr(dentry, want_extra_bits, force);
> ? ? ? ?if (rc)
> ? ? ? ? ? ? ? ?return rc;
>
> @@ -1796,11 +1816,30 @@ int cifs_revalidate_dentry(struct dentry *dentry)
> ?int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> ? ? ? ? ? ? ? ? struct kstat *stat)
> ?{
> + ? ? ? struct cifsInodeInfo *cifs_i = CIFS_I(dentry->d_inode);
> ? ? ? ?struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb);
> ? ? ? ?struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
> ? ? ? ?struct inode *inode = dentry->d_inode;
> + ? ? ? unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC;
> + ? ? ? bool want_extra_bits = false;
> + ? ? ? u32 info, ioc = 0;
> + ? ? ? u32 attrs;
> ? ? ? ?int rc;
>
> + ? ? ? if (cifs_i->uid_faked)
> + ? ? ? ? ? ? ? stat->request_mask &= ~XSTAT_UID;
> + ? ? ? if (cifs_i->gid_faked)
> + ? ? ? ? ? ? ? stat->request_mask &= ~XSTAT_GID;
> +
> + ? ? ? if (stat->request_mask & XSTAT_BTIME && !cifs_i->btime_valid) {
> + ? ? ? ? ? ? ? want_extra_bits = true;
> + ? ? ? ? ? ? ? force = true;
> + ? ? ? }
> + ? ? ? if (stat->request_mask & XSTAT_IOC_FLAGS) {
> + ? ? ? ? ? ? ? want_extra_bits = true;
> + ? ? ? ? ? ? ? force = true;
> + ? ? ? }
> +
> ? ? ? ?/*
> ? ? ? ? * We need to be sure that all dirty pages are written and the server
> ? ? ? ? * has actual ctime, mtime and file length.
> @@ -1814,13 +1853,14 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> - ? ? ? rc = cifs_revalidate_dentry_attr(dentry);
> - ? ? ? if (rc)
> - ? ? ? ? ? ? ? return rc;
> + ? ? ? if (force || stat->request_mask & XSTAT_BASIC_STATS) {
> + ? ? ? ? ? ? ? rc = cifs_revalidate_dentry(dentry, want_extra_bits, force);
> + ? ? ? ? ? ? ? if (rc)
> + ? ? ? ? ? ? ? ? ? ? ? return rc;
> + ? ? ? }
>
> ? ? ? ?generic_fillattr(inode, stat);
> ? ? ? ?stat->blksize = CIFS_MAX_MSGSIZE;
> - ? ? ? stat->ino = CIFS_I(inode)->uniqueid;
>
> ? ? ? ?/*
> ? ? ? ? * If on a multiuser mount without unix extensions, and the admin hasn't
> @@ -1834,7 +1874,53 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> ? ? ? ? ? ? ? ?if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID))
> ? ? ? ? ? ? ? ? ? ? ? ?stat->gid = current_fsgid();
> ? ? ? ?}
> - ? ? ? return rc;
> +
> + ? ? ? info = XSTAT_INFO_REMOTE | XSTAT_INFO_NONSYSTEM_OWNERSHIP;
> +#ifdef CONFIG_CIFS_ACL
> + ? ? ? info |= XSTAT_INFO_HAS_ACL;
> +#endif
> +
> + ? ? ? if (cifs_i->btime_valid) {
> + ? ? ? ? ? ? ? stat->btime = cifs_i->btime;
> + ? ? ? ? ? ? ? stat->result_mask |= XSTAT_BTIME;
> + ? ? ? }
> +
> + ? ? ? /* We don't promise an inode number if we made one up */
> + ? ? ? stat->ino = cifs_i->uniqueid;
> + ? ? ? if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM))
> + ? ? ? ? ? ? ? stat->result_mask &= ~XSTAT_INO;
> +
> + ? ? ? /*
> + ? ? ? ?* If on a multiuser mount without unix extensions, and the admin
> + ? ? ? ?* hasn't overridden them, set the ownership to the fsuid/fsgid of the
> + ? ? ? ?* current process.
> + ? ? ? ?*/
> + ? ? ? if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MULTIUSER) &&
> + ? ? ? ? ? !tcon->unix_ext) {
> + ? ? ? ? ? ? ? if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID))
> + ? ? ? ? ? ? ? ? ? ? ? stat->uid = current_fsuid();
> + ? ? ? ? ? ? ? if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID))
> + ? ? ? ? ? ? ? ? ? ? ? stat->gid = current_fsgid();
> + ? ? ? }
> + ? ? ? if (cifs_i->uid_faked)
> + ? ? ? ? ? ? ? stat->result_mask &= ~XSTAT_UID;
> + ? ? ? if (cifs_i->gid_faked)
> + ? ? ? ? ? ? ? stat->result_mask &= ~XSTAT_GID;
> +
> + ? ? ? attrs = cifs_i->cifsAttrs;
> + ? ? ? if (attrs & ATTR_HIDDEN) ? ? ? ?info |= XSTAT_INFO_HIDDEN;
> + ? ? ? if (attrs & ATTR_SYSTEM) ? ? ? ?info |= XSTAT_INFO_SYSTEM;
> + ? ? ? if (attrs & ATTR_ARCHIVE) ? ? ? info |= XSTAT_INFO_ARCHIVE;
> + ? ? ? if (attrs & ATTR_TEMPORARY) ? ? info |= XSTAT_INFO_TEMPORARY;
> + ? ? ? if (attrs & ATTR_REPARSE) ? ? ? info |= XSTAT_INFO_REPARSE_POINT;
> + ? ? ? if (attrs & ATTR_OFFLINE) ? ? ? info |= XSTAT_INFO_OFFLINE;
> + ? ? ? if (attrs & ATTR_ENCRYPTED) ? ? info |= XSTAT_INFO_ENCRYPTED;
> + ? ? ? stat->information |= info;
> +
> + ? ? ? if (attrs & ATTR_READONLY) ? ? ?ioc |= FS_IMMUTABLE_FL;
> + ? ? ? if (attrs & ATTR_COMPRESSED) ? ?ioc |= FS_COMPR_FL;
> + ? ? ? stat->ioc_flags |= ioc;
> + ? ? ? return 0;
> ?}
>
> ?static int cifs_truncate_page(struct address_space *mapping, loff_t from)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

--
Thanks,

Steve

2012-04-26 17:01:26

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDExOjU2IC0wNTAwLCBTdGV2ZSBGcmVuY2ggd3JvdGU6DQo+
IE9uIFRodSwgQXByIDI2LCAyMDEyIGF0IDEwOjI1IEFNLCBNeWtsZWJ1c3QsIFRyb25kDQo+IDxU
cm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4gd3JvdGU6DQo+ID4gT24gVGh1LCAyMDEyLTA0LTI2
IGF0IDA5OjU0IC0wNTAwLCBTdGV2ZSBGcmVuY2ggd3JvdGU6DQo+ID4+IE9uIFRodSwgQXByIDI2
LCAyMDEyIGF0IDk6MjUgQU0sIERhdmlkIEhvd2VsbHMgPGRob3dlbGxzQHJlZGhhdC5jb20+IHdy
b3RlOg0KPiA+PiA+IFN0ZXZlIEZyZW5jaCA8c21mcmVuY2hAZ21haWwuY29tPiB3cm90ZToNCj4g
Pj4gPg0KPiA+PiA+PiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gbWFrZSB0aGUgc3RhYmxlIHZzIHZv
bGF0aWxlIGlub2RlIG51bWJlciBhbiBhdHRyaWJ1dGUNCj4gPj4gPj4gb2YgdGhlIHZvbHVtZSAg
b3Igc29tZXRoaW5nIHJldHVybmVkIGJ5IHRoZSBwcm9wb3NlZCB4c3RhdD8NCj4gPj4gPg0KPiA+
PiA+IEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IGEgc3RhYmxlIHZzIGEgdm9sYXRpbGUg
aW5vZGUgbnVtYmVyLg0KPiA+Pg0KPiA+PiBCb3RoIE5GUyBhbmQgQ0lGUyAoYW5kIFNNQjIpIGNh
biByZXR1cm4gaW5vZGUgbnVtYmVycyBvciBlcXVpdmFsZW50DQo+ID4+IHVuaXF1ZSBpZGVudGlm
aWVyLCBidXQgaW4gdGhlIGNhc2Ugb2YgQ0lGUyBzb21lIG9sZCBzZXJ2ZXJzIGRvbid0IHN1cHBv
cnQgdGhlDQo+ID4+IGNhbGxzIHdoaWNoIHJldHVybiBpbm9kZSBudW1iZXJzIChvciBkb24ndCBy
ZXR1cm4gdGhlbSBmb3IgYWxsIGZpbGUgc3lzdGVtDQo+ID4+IHR5cGVzLCBXaW5kb3dzIEZBVD8p
IHNvIGluIHRoZXNlIGNhc2VzIGNpZnMgaGFzIHRvIGNyZWF0ZSBpbm9kZQ0KPiA+PiBudW1iZXJz
IG9uIHRoZSBmbHkNCj4gPj4gb24gdGhlIGNsaWVudC4gICBpbm9kZSBudW1iZXJzIGNyZWF0ZWQg
b24gdGhlIGNsaWVudCBhcmUgbm90ICJzdGFibGUiIHRoZXkNCj4gPj4gY2FuIGNoYW5nZSBvbiB1
bm1vdW50L3JlbW91bnQgKHdoaWNoIGNhbiBjYXVzZSBwcm9ibGVtcyBmb3IgYmFja3VwDQo+ID4+
IGFwcGxpY2F0aW9ucykuDQo+ID4+DQo+ID4+IFNpbWlsYXJseSBORlN2NCBkb2VzIG5vdCByZXF1
aXJlIHRoYXQgc2VydmVycyBhbHdheXMgcmV0dXJuIHN0YWJsZSBpbm9kZSBudW1iZXJzDQo+ID4+
ICh0aGF0IHdpbGwgbmV2ZXIgY2hhbmdlKSBhbmQgaW50cm9kdWNlZCBhIGNvbmNlcHQgb2YgInZv
bGF0aWxlIGZpbGUgaGFuZGxlLiINCj4gPj4gV2UgaGF2ZSBydW4gaW50byB0aGlzIGluIHR3byBj
YXNlcyAodGhlcmUgYXJlIHByb2JhYmx5IG1vcmUpIC0NCj4gPj4gU3BlY2lhbGl6ZWQgTkZTIHNl
cnZlcnMNCj4gPj4gZm9yIEhQQyB3aGljaCBkZWFsIHdpdGggbG90cyBvZiB0cmFuc2llbnQgaW5v
ZGVzLCBhbmQgc2Vjb25kIHRob3NlIGZvciBzZXJ2ZXJzDQo+ID4+IHdoaWNoIGJhc2UgdGhlcmUg
aW5vZGUgbnVtYmVyIG9uIHBhdGggKFdpbmRvd3MgTkZTPykuICBTZWUNCj4gPj4gaHR0cDovL2Rv
Y3Mub3JhY2xlLmNvbS9jZC9FMTkwODItMDEvODE5LTE2MzQvcmZzcmVmZXItMTM3L2luZGV4Lmh0
bWwNCj4gPj4gb3IgdGhlIE5GU3Y0IFJGQy4NCj4gPj4NCj4gPj4gQmFzaWNhbGx5IHRoZSBxdWVz
dGlvbiBpcyB3aGV0aGVyIGl0IGlzIHdvcnRoIHJlcG9ydGluZyBhIGZsYWcgb24gdGhlDQo+ID4+
IGNhbGwgd2hpY2ggcmV0dXJucw0KPiA+PiB0aGUgaW5vZGUgbnVtYmVyIHRvIGluZGljYXRlIHRo
YXQgdGhlIGlub2RlIG51bWJlciBpcyAic3RhYmxlIiAod291bGQgbm90IGNoYW5nZQ0KPiA+PiBv
biByZWJvb3Qgb3IgcmVjb25uZWN0aW9uKSBvciAidm9sYXRpbGUuIiAgICBTaW5jZSB0aGUgbWFq
b3JpdHkgb2YgTkZTDQo+ID4+IGFuZCBTTUIyIHNlcnZlcnMNCj4gPj4gY2FuIHJldHVybiBzdGFi
bGUgaW5vZGUgbnVtYmVycywgSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoZSBuZWVkDQo+
ID4+IGZvciBhbiBpbmRpY2F0b3INCj4gPj4gb2YgInN0YWJsZSIgdnMuICJ2b2xhdGlsZSIgYnV0
IEkgbWVudGlvbiBpdCBiZWNhdXNlIGJhY2t1cCBhbmQNCj4gPj4gbWlncmF0aW9uIGFwcGxpY2F0
aW9ucw0KPiA+PiBtZW50aW9uIHRoaXMgKGlmIGlub2RlIG51bWJlcnMgYXJlIHZvbGF0aWxlLCB0
aGV5IG1heSBoYXZlIHRvIGNoZWNrDQo+ID4+IGZvciBoYXJkbGlua3MgZGlmZmVyZW50bHkNCj4g
Pj4gZm9yIGV4YW1wbGUpDQo+ID4NCj4gPiBJIGRvbid0IHVuZGVyc3RhbmQuIElmIHRoZSBmaWxl
c3lzdGVtIGRvZXNuJ3Qgc3VwcG9ydCByZWFsIGlub2RlDQo+ID4gbnVtYmVycywgdGhlbiB3aHkg
cmVwb3J0IHRoZW0gYXQgYWxsPyBXaGF0IHVzZSB3b3VsZCBhbiBhcHBsaWNhdGlvbiBoYXZlDQo+
ID4gZm9yIGFuIGlub2RlIG51bWJlciB0aGF0IGNhbid0IGJlIHVzZWQgdG8gaWRlbnRpZnkgaGFy
ZCBsaW5rZWQgZmlsZXM/DQo+IA0KPiBXZWxsIC4uLiB5b3UgaGF2ZSB0byBoYXZlIGFuIGlub2Rl
IG51bWJlciBvbiB0aGUgTGludXggY2xpZW50IHNpZGUgZXZlbiBpZg0KPiB0aGUgc2VydmVyIGRv
ZXNuJ3QgcmVwb3J0IHRoZW0gKG9yIGhhcyBhIGJ1ZyBhbmQgcmVwb3J0cyBkdXBsaWNhdGVzKS4N
Cj4gSWYgeW91IGNhbid0IHRlbGwgaGFyZGxpbmtlZCBmaWxlcyBhcGFydCBmaXggdGhlIHNlcnZl
ciAoYnV0IGluIHRoZQ0KPiBjYXNlcyB3aGVyZSB0aGUgZmlsZSBzeXN0ZW1zIGhhcyB0aGlzIHBy
b2JsZW0gdGhlIHNlcnZlciBkb2Vzbid0IHVzdWFsbHkNCj4gc3VwcG9ydCBoYXJkbGlua3MgZWl0
aGVyKS4NCj4gDQo+IElmIHRoZSBzZXJ2ZXIncyBmaWxlIHN5c3RlbSBpbnRlcm5hbCBzdHJ1Y3R1
cmVzIGRvbid0IHN1cHBvcnQgcmVhbCBpbm9kZQ0KPiBudW1iZXJzIChzdWNoIGFzIEZBVCBvciBh
IHJhbWRpc2spIHRoZW4gaXQgZWl0aGVyIGhhcyB0byBtYWtlIHRoZW0NCj4gdXAgYmFzZWQgb24g
c29tZXRoaW5nIGxpa2UgcGF0aCBuYW1lIG9yIHNvbWUgb3RoZXIgYXR0cmlidXRlIG9mIHRoZQ0K
PiBmaWxlIG9uIGRpc2suDQo+IA0KPiBTZXJ2ZXJzIGxpa2UgTmV0QXBwIGlzIHdoZXJlIHRoaXMg
Z2V0cyBpbnRlcmVzdGluZyAtIGZvciBjaWZzIGUuZy4gbGV2ZWwgMTAwOQ0KPiBxdWVyeSBmaWxl
IGluZm8gaXMgdXNlZCB0byBxdWVyeV9maWxlX2ludGVybmFsX2luZm8gKHRoZSBpbm9kZSBudW1i
ZXIpIGJ1dA0KPiB3aGF0IGlmIHRoZSBzZXJ2ZXIgY2FuIG5vdCByZXBvcnQgaW5vZGUgbnVtYmVy
cyAoZHVlIHRvIGEgYnVnKSBpbg0KPiBhbGwgY2FzZXMuDQoNClJpZ2h0LCBidXQgbm9uZSBvZiB0
aGlzIGV4cGxhaW5zIHdoeSB3ZSBuZWVkIHRvIHJlcG9ydCB0aGVzZSBib2d1cyBpbm9kZQ0KbnVt
YmVycyB0byB0aGUgYXBwbGljYXRpb24gaW4gdGhlIHhzdGF0KCkgcmVwbHkuDQoNCi0tIA0KVHJv
bmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpUcm9u
ZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg0K

2012-04-19 23:06:02

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

statx seems like a better family of names. I also think it's worthwhile to
see if the interface can be made to more closely match the AIX precedent.

Thanks,
Roland

2012-04-26 13:41:01

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

J. Bruce Fields <[email protected]> wrote:

> > (11) Include granularity fields in the time data to indicate the
> > granularity of each of the times (NFSv4 time_delta) [Steve French].
>
> It looks like you're including this with *each* time? But surely
> there's no filesystem with different granularity (say) for ctime than
> for mtime.

I put it in each time struct to use up the hole there. I could, I suppose,
split tv_sec from tv_nsec to get rid of the holes and then put the granularity
separately. That means that someone who wanted both the tv_sec and tv_nsec
would have to fish them out separately, but that's probably okay.

I could even make the granularity bigger then, to allow for the possibility of
having a granularity >4s, but I don't know of anywhere that requires a gran >2.

> Also, nfsd will want only one time_delta, not one for each time.

time_delta? Is that the same as granularity?

> Note also we need to document carefully what this means: I think it
> should be the granularity that the filesystem is capable of
> representing, but people are sometimes surprised to find out that the
> actual time source is usually more coarse-grained than that.

Yeah, but the latter is something you may not be able to determine, and may
indeed change over time (say someone updates the server kernel to one with a
more fine-grained software clock). Also, for a network fs, it may depend on
the client that happened to set that time last.

David

2012-04-27 03:15:57

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 2012-04-26, at 10:52, David Howells <[email protected]> wrote:

> Steve French <[email protected]> wrote:
>>
>> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent unique
>> identifier, but in the case of CIFS some old servers don't support the calls
>> which return inode numbers (or don't return them for all file system types,
>> Windows FAT?) so in these cases cifs has to create inode numbers on the fly
>> on the client. inode numbers created on the client are not "stable" they can
>> change on unmount/remount (which can cause problems for backup applications).
>
> In the volatile case you'd probably want to unset XSTAT_INO in st_mask as the
> inode number is a local fabrication.

I'd agree. Why fake up an inode number if the application doesn't care? Most apps don't actually use the inode. The only uses I know for the inode number in userspace are backup, CIFS/NFS servers, and "ls -li" .

> However, since there is a remote file ID,
> we could add an XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr
> holding this.

It is a bit strange that the kernel would return a flag that was not requested, but not fatal.

> On CIFS this could be the servername + pathname, on NFS this
> could be the server address + FH on AFS the cell+volID+FID+uniquifier for
> example. That's independent of xstat, however, and wouldn't be returned as
> it's a blob that could be quite large.
>
> I presume in some cases, there is not a unique file ID that persists across
> rename.
>
>> Similarly NFSv4 does not require that servers always return stable inode
>> numbers (that will never change) and introduced a concept of "volatile file
>> handle."
>
> Can I presume the inode number cannot be considered stable if the NFS4 FH is
> non-volatile? Furthermore, can I presume NFS2/3 inode numbers are supposed to
> be stable?
>
>> Basically the question is whether it is worth reporting a flag on the call
>> which returns the inode number to indicate that the inode number is "stable"
>> (would not change on reboot or reconnection) or "volatile." Since the
>> majority of NFS and SMB2 servers can return stable inode numbers, I don't
>> feel strongly about the need for an indicator of "stable" vs. "volatile" but
>> I mention it because backup and migration applications mention this (if inode
>> numbers are volatile, they may have to check for hardlinks differently for
>> example)
>
> It may be that unsetting XSTAT_INO if you've fabricated the inode number
> locally is sufficient.
>
>>>>> Handle remote filesystems being offline and indicate this with
>>>>> XSTAT_INFO_OFFLINE.
>>>>
>>>> You already have support for an indicator for offline files (HSM),
>
> Which indicator is this? Or do you mean XSTAT_INFO_OFFLINE?
>
>>>> would XSTAT_INFO_OFFLINE be intended for the case
>>>> where the network session to the server is disconnected
>>>> (and in which you case the application does not want to reconnect)?
>>>
>>> Hmmm... Interesting question. Both NTFS and CIFS have an offline
>>> attribute (which is where I originally got this from) - but should I have a
>>> separate indicator to indicate the client can't access a server over a
>>> network (ie. we've gone to disconnected operation on this file)?
>>> E.g. should there be a XSTAT_INFO_DISCONNECTED too?
>>
>> my reaction is no, since it adds complexity. If you do a stat on a
>> disconnected volume (where the network is temporarily down) reconnection will
>> be attempted. If reconnection fails then the xstat will either fail or be
>> retried forever depending on the value of "hard" vs. "soft" mount flag.
>
> I was thinking of how to handle disconnected operation, where you can't just
> sit there and churn waiting for the server to come back or give an error. On
> the other hand, as long as there's some spare space in the struct, we can deal
> with that later when we actually start to implement D/O.
>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2012-04-19 14:07:26

[permalink] [raw]

Subject: [PATCH 2/6] xstat: Ext4: Return extended attributes

Return extended attributes from the Ext4 filesystem. This includes the
following:

(1) The inode creation time (i_crtime) as i_btime.

(2) The inode i_generation as i_gen if not the root directory.

(3) The inode i_version as st_data_version if a file with I_VERSION set or a
directory.

(4) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS).

Signed-off-by: David Howells <[email protected]>
---

fs/ext4/ext4.h | 2 ++
fs/ext4/file.c | 2 +-
fs/ext4/inode.c | 32 +++++++++++++++++++++++++++++---
fs/ext4/namei.c | 2 ++
fs/ext4/super.c | 1 +
fs/ext4/symlink.c | 2 ++
6 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index ab2594a..81806da 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1899,6 +1899,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat);
extern void ext4_evict_inode(struct inode *);
extern void ext4_clear_inode(struct inode *);
+extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat);
extern int ext4_sync_inode(handle_t *, struct inode *);
extern void ext4_dirty_inode(struct inode *, int);
extern int ext4_change_inode_journal_flag(struct inode *, int);
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index cb70f18..ae8654c 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -249,7 +249,7 @@ const struct file_operations ext4_file_operations = {

const struct inode_operations ext4_file_inode_operations = {
.setattr = ext4_setattr,
- .getattr = ext4_getattr,
+ .getattr = ext4_file_getattr,
#ifdef CONFIG_EXT4_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index c77b0bd..eafc188 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4191,11 +4191,37 @@ err_out:
int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat)
{
- struct inode *inode;
- unsigned long delalloc_blocks;
+ struct inode *inode = dentry->d_inode;
+ struct ext4_inode_info *ei = EXT4_I(inode);
+
+ stat->result_mask |= XSTAT_BTIME;
+ stat->btime.tv_sec = ei->i_crtime.tv_sec;
+ stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
+
+ if (inode->i_ino != EXT4_ROOT_INO) {
+ stat->result_mask |= XSTAT_GEN;
+ stat->gen = inode->i_generation;
+ }
+ if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) {
+ stat->result_mask |= XSTAT_VERSION;
+ stat->version = inode->i_version;
+ }
+
+ ext4_get_inode_flags(ei);
+ stat->ioc_flags |= ei->i_flags & EXT4_FL_USER_VISIBLE;
+ stat->result_mask |= XSTAT_IOC_FLAGS;

- inode = dentry->d_inode;
generic_fillattr(inode, stat);
+ return 0;
+}
+
+int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat)
+{
+ struct inode *inode = dentry->d_inode;
+ u64 delalloc_blocks;
+
+ ext4_getattr(mnt, dentry, stat);

/*
* We can't update i_blocks if the block allocation is delayed
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 349d7b3..6162387 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2579,6 +2579,7 @@ const struct inode_operations ext4_dir_inode_operations = {
.mknod = ext4_mknod,
.rename = ext4_rename,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
#ifdef CONFIG_EXT4_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
@@ -2591,6 +2592,7 @@ const struct inode_operations ext4_dir_inode_operations = {

const struct inode_operations ext4_special_inode_operations = {
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
#ifdef CONFIG_EXT4_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ceebaf8..2d395bf 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3040,6 +3040,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
if (sb->s_magic != EXT4_SUPER_MAGIC)
goto cantfind_ext4;
sbi->s_kbytes_written = le64_to_cpu(es->s_kbytes_written);
+ memcpy(sb->s_volume_id, es->s_uuid, sizeof(sb->s_volume_id));

/* Set defaults before we parse the mount options */
def_mount_opts = le32_to_cpu(es->s_default_mount_opts);
diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
index ed9354a..d8fe7fb 100644
--- a/fs/ext4/symlink.c
+++ b/fs/ext4/symlink.c
@@ -35,6 +35,7 @@ const struct inode_operations ext4_symlink_inode_operations = {
.follow_link = page_follow_link_light,
.put_link = page_put_link,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
#ifdef CONFIG_EXT4_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
@@ -47,6 +48,7 @@ const struct inode_operations ext4_fast_symlink_inode_operations = {
.readlink = generic_readlink,
.follow_link = ext4_follow_link,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
#ifdef CONFIG_EXT4_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,

2012-04-26 17:09:39

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond
<[email protected]> wrote:
> On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
>> <[email protected]> wrote:
>> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
>> >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
>> >> <[email protected]> wrote:
>> >> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
>> >> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <[email protected]> wrote:
>> >> >> > Steve French <[email protected]> wrote:
>> >> >> >
>> >> >> >> Would it be better to make the stable vs volatile inode number an attribute
>> >> >> >> of the volume ?or something returned by the proposed xstat?
>> >> >> >
>> >> >> > I'm not sure what you mean by a stable vs a volatile inode number.
>> >> >>
>> >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
>> >> >> unique identifier, but in the case of CIFS some old servers don't support the
>> >> >> calls which return inode numbers (or don't return them for all file system
>> >> >> types, Windows FAT?) so in these cases cifs has to create inode
>> >> >> numbers on the fly
>> >> >> on the client. ? inode numbers created on the client are not "stable" they
>> >> >> can change on unmount/remount (which can cause problems for backup
>> >> >> applications).
>> >> >>
>> >> >> Similarly NFSv4 does not require that servers always return stable inode numbers
>> >> >> (that will never change) and introduced a concept of "volatile file handle."
>> >> >> We have run into this in two cases (there are probably more) -
>> >> >> Specialized NFS servers
>> >> >> for HPC which deal with lots of transient inodes, and second those for servers
>> >> >> which base there inode number on path (Windows NFS?). ?See
>> >> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
>> >> >> or the NFSv4 RFC.
>> >> >>
>> >> >> Basically the question is whether it is worth reporting a flag on the
>> >> >> call which returns
>> >> >> the inode number to indicate that the inode number is "stable" (would not change
>> >> >> on reboot or reconnection) or "volatile." ? ?Since the majority of NFS
>> >> >> and SMB2 servers
>> >> >> can return stable inode numbers, I don't feel strongly about the need
>> >> >> for an indicator
>> >> >> of "stable" vs. "volatile" but I mention it because backup and
>> >> >> migration applications
>> >> >> mention this (if inode numbers are volatile, they may have to check
>> >> >> for hardlinks differently
>> >> >> for example)
>> >> >
>> >> > I don't understand. If the filesystem doesn't support real inode
>> >> > numbers, then why report them at all? What use would an application have
>> >> > for an inode number that can't be used to identify hard linked files?
>> >>
>> >> Well ... you have to have an inode number on the Linux client side even if
>> >> the server doesn't report them (or has a bug and reports duplicates).
>> >> If you can't tell hardlinked files apart fix the server (but in the
>> >> cases where the file systems has this problem the server doesn't usually
>> >> support hardlinks either).
>> >>
>> >> If the server's file system internal structures don't support real inode
>> >> numbers (such as FAT or a ramdisk) then it either has to make them
>> >> up based on something like path name or some other attribute of the
>> >> file on disk.
>> >>
>> >> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009
>> >> query file info is used to query_file_internal_info (the inode number) but
>> >> what if the server can not report inode numbers (due to a bug) in
>> >> all cases.
>> >
>> > Right, but none of this explains why we need to report these bogus inode
>> > numbers to the application in the xstat() reply.
>>
>> the question is whether the application (backup) would need to know
>> that the inode numbers are bogus and from my conversations with
>> guys writing backup software it seems that such data is useful to them.
>
> You are still not explaining why they need to know the values at all? If
> the values are bogus, then don't return them, and don't set the flag
> that says they are being returned.

I don't know, but assumed it was because it was an easy way
to index them since the inode numbers even if they "change"
on remount, are still unique.

--
Thanks,

Steve

2012-04-26 13:48:13

[permalink] [raw]

Subject: Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

Steve French <[email protected]> wrote:

> This patch reminds me of a question on time stamps - how can an
> application query the time granularity ie sb_s_time_gran for a mount
> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
> nanosecond for others etc.)

Ummm... In what context? With the proposed xstat() interface it will be
provided.

David

2012-04-26 22:02:45

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

> fileinfoat() perhaps? I think stat*at() is better, though, as people are
> used to the stat function family.

Names like that were all I had thought of when I said I hadn't thought of
any good ones. ;-)

2012-04-19 14:07:40

[permalink] [raw]

Subject: [PATCH 4/6] xstat: NFS: Return extended attributes

Return extended attributes from the NFS filesystem. This includes the
following:

(1) The change attribute as st_data_version if NFSv4.

(2) XSTAT_INFO_AUTOMOUNT and XSTAT_INFO_FABRICATED are set on referral or
submount directories that are automounted upon. NFS shows one directory
with a different FSID, but the local filesystem has two: the mountpoint
directory and the root of the filesystem mounted upon it.

(3) XSTAT_INFO_REMOTE is set on files acquired over NFS.

Furthermore, what nfs_getattr() does can be controlled as follows:

(1) If AT_FORCE_ATTR_SYNC is indicated, or mtime, ctime or data_version (NFSv4
only) are requested then the outstanding writes will be written to the
server first.

(2) The inode's attributes may be synchronised with the server:

(a) If AT_FORCE_ATTR_SYNC is indicated or if atime is requested (and atime
updating is not suppressed by a mount flag) then the attributes will
be reread unconditionally.

(b) If the data version or any of basic stats are requested then the
attributes will be reread if the cached attributes have expired.

(c) Otherwise the cached attributes will be used - even if expired -
without reference to the server.

Signed-off-by: David Howells <[email protected]>
---

fs/nfs/inode.c | 49 +++++++++++++++++++++++++++++++++++++------------
fs/nfs/super.c | 1 +
2 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index e8bbfa5..460fcf3 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -509,11 +509,18 @@ void nfs_setattr_update_inode(struct inode *inode, struct iattr *attr)
int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
{
struct inode *inode = dentry->d_inode;
+ unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC;
int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
int err;

- /* Flush out writes to the server in order to update c/mtime. */
- if (S_ISREG(inode->i_mode)) {
+ if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4)
+ stat->request_mask &= ~XSTAT_VERSION;
+
+ /* Flush out writes to the server in order to update c/mtime
+ * or data version if the user wants them */
+ if ((force || (stat->request_mask &
+ (XSTAT_MTIME | XSTAT_CTIME | XSTAT_VERSION))) &&
+ S_ISREG(inode->i_mode)) {
err = filemap_write_and_wait(inode->i_mapping);
if (err)
goto out;
@@ -528,18 +535,36 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
* - NFS never sets MS_NOATIME or MS_NODIRATIME so there is
* no point in checking those.
*/
- if ((mnt->mnt_flags & MNT_NOATIME) ||
- ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
+ if (mnt->mnt_flags & MNT_NOATIME ||
+ (mnt->mnt_flags & MNT_NODIRATIME && S_ISDIR(inode->i_mode))) {
+ stat->ioc_flags |= FS_NOATIME_FL;
+ need_atime = 0;
+ } else if (!(stat->request_mask & XSTAT_ATIME)) {
need_atime = 0;
+ }

- if (need_atime)
- err = __nfs_revalidate_inode(NFS_SERVER(inode), inode);
- else
- err = nfs_revalidate_inode(NFS_SERVER(inode), inode);
- if (!err) {
- generic_fillattr(inode, stat);
- stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
+ if (force || stat->request_mask & (XSTAT_BASIC_STATS | XSTAT_VERSION)) {
+ if (force || need_atime)
+ err = __nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ else
+ err = nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ if (err)
+ goto out;
}
+
+ generic_fillattr(inode, stat);
+ stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
+
+ if (stat->request_mask & XSTAT_VERSION) {
+ stat->version = inode->i_version;
+ stat->result_mask |= XSTAT_VERSION;
+ }
+
+ if (IS_AUTOMOUNT(inode))
+ stat->information |= XSTAT_INFO_FABRICATED;
+
+ stat->information |= XSTAT_INFO_REMOTE;
+
out:
return err;
}
@@ -852,7 +877,7 @@ int nfs_revalidate_inode(struct nfs_server *server, struct inode *inode)
static int nfs_invalidate_mapping(struct inode *inode, struct address_space *mapping)
{
struct nfs_inode *nfsi = NFS_I(inode);
-
+
if (mapping->nrpages != 0) {
int ret = invalidate_inode_pages2(mapping);
if (ret < 0)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 37412f7..faa652c 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2222,6 +2222,7 @@ static int nfs_set_super(struct super_block *s, void *data)
ret = set_anon_super(s, server);
if (ret == 0)
server->s_dev = s->s_dev;
+ memcpy(&s->s_volume_id, &server->fsid, sizeof(s->s_volume_id));
return ret;
}

2012-04-26 16:56:18

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
<[email protected]> wrote:
> On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <[email protected]> wrote:
>> > Steve French <[email protected]> wrote:
>> >
>> >> Would it be better to make the stable vs volatile inode number an attribute
>> >> of the volume ?or something returned by the proposed xstat?
>> >
>> > I'm not sure what you mean by a stable vs a volatile inode number.
>>
>> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
>> unique identifier, but in the case of CIFS some old servers don't support the
>> calls which return inode numbers (or don't return them for all file system
>> types, Windows FAT?) so in these cases cifs has to create inode
>> numbers on the fly
>> on the client. ? inode numbers created on the client are not "stable" they
>> can change on unmount/remount (which can cause problems for backup
>> applications).
>>
>> Similarly NFSv4 does not require that servers always return stable inode numbers
>> (that will never change) and introduced a concept of "volatile file handle."
>> We have run into this in two cases (there are probably more) -
>> Specialized NFS servers
>> for HPC which deal with lots of transient inodes, and second those for servers
>> which base there inode number on path (Windows NFS?). ?See
>> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
>> or the NFSv4 RFC.
>>
>> Basically the question is whether it is worth reporting a flag on the
>> call which returns
>> the inode number to indicate that the inode number is "stable" (would not change
>> on reboot or reconnection) or "volatile." ? ?Since the majority of NFS
>> and SMB2 servers
>> can return stable inode numbers, I don't feel strongly about the need
>> for an indicator
>> of "stable" vs. "volatile" but I mention it because backup and
>> migration applications
>> mention this (if inode numbers are volatile, they may have to check
>> for hardlinks differently
>> for example)
>
> I don't understand. If the filesystem doesn't support real inode
> numbers, then why report them at all? What use would an application have
> for an inode number that can't be used to identify hard linked files?

Well ... you have to have an inode number on the Linux client side even if
the server doesn't report them (or has a bug and reports duplicates).
If you can't tell hardlinked files apart fix the server (but in the
cases where the file systems has this problem the server doesn't usually
support hardlinks either).

If the server's file system internal structures don't support real inode
numbers (such as FAT or a ramdisk) then it either has to make them
up based on something like path name or some other attribute of the
file on disk.

Servers like NetApp is where this gets interesting - for cifs e.g. level 1009
query file info is used to query_file_internal_info (the inode number) but
what if the server can not report inode numbers (due to a bug) in
all cases.

--
Thanks,

Steve

2012-04-26 18:25:26

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

> I've no particular attachment to the name 'xstat'. If you'd prefer 'statx' I
> could go for that.

I prefer something other than xstat and statx(at) seems acceptable enough.
What I'd really prefer is a name that is less meaninglessly arcane,
but I haven't thought of any good ones.

Thanks,
Roland

2012-04-19 14:23:34

[permalink] [raw]

Subject: [PATCH 5/6] xstat: CIFS: Return extended attributes

Return extended attributes from the CIFS filesystem. This includes the
following:

(1) Return the file creation time as btime. We assume that the creation time
won't change over the life of the inode.

(2) Set XSTAT_INFO_AUTOMOUNT on referral/submount directories.

(3) Unset XSTAT_INO if we made up the inode number and didn't get it from the
server.

(4) Unset XSTAT_[UG]ID if we are either returning values passed to mount
and/or the server doesn't return them.

(5) Map various Windows file attributes to FS_xxx_FL flags in st_ioc_flags
and XSTAT_INFO_xxx flags in st_information, fetching them from the server
if we don't have them yet or don't have a current copy.

Possibly things like Hidden, System and Archive should be FS_xxx_FL flags
rather than XSTAT_INFO_xxx flags and st_ioc_flags should be expanded to
64 bits.

(6) Set XSTAT_INFO_REMOTE on all files fetched by CIFS.

(7) Set XSTAT_INFO_NONSYSTEM_OWNERSHIP on all files as they all have Windows
ownership details too.

(8) Set XSTAT_INFO_HAS_ACL if CONFIG_CIFS_ACL=y as Windows ACLs are available
on the object.

Furthermore, what cifs_getattr() does can be controlled as follows:

(1) If AT_FORCE_ATTR_SYNC is indicated, or if the inode flags or creation time
are requested but not yet collected, then the attributes will be reread
unconditionally.

(2) If the basic stats are requested or if the inode flags are requested and
have been collected previously, then the attributes will be reread if out
of date.

(3) Otherwise the cached attributes will be used - even if expired - without
reference to the server.

Note that cifs_revalidate_dentry() will issue an extra operation to get the
FILE_ALL_INFO in addition to the FILE_UNIX_BASIC_INFO if it needs to collect
creation time and attributes on behalf of cifs_getattr().

[NOTE: THIS PATCH IS UNTESTED!]

Signed-off-by: David Howells <[email protected]>
---

fs/cifs/cifsfs.h | 4 +-
fs/cifs/cifsglob.h | 16 +++++--
fs/cifs/dir.c | 2 -
fs/cifs/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++-------
4 files changed, 118 insertions(+), 24 deletions(-)

diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h
index d1389bb..021e327 100644
--- a/fs/cifs/cifsfs.h
+++ b/fs/cifs/cifsfs.h
@@ -56,9 +56,9 @@ extern int cifs_rmdir(struct inode *, struct dentry *);
extern int cifs_rename(struct inode *, struct dentry *, struct inode *,
struct dentry *);
extern int cifs_revalidate_file_attr(struct file *filp);
-extern int cifs_revalidate_dentry_attr(struct dentry *);
+extern int cifs_revalidate_dentry_attr(struct dentry *, bool, bool);
extern int cifs_revalidate_file(struct file *filp);
-extern int cifs_revalidate_dentry(struct dentry *);
+extern int cifs_revalidate_dentry(struct dentry *, bool, bool);
extern int cifs_invalidate_mapping(struct inode *inode);
extern int cifs_getattr(struct vfsmount *, struct dentry *, struct kstat *);
extern int cifs_setattr(struct dentry *, struct iattr *);
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index 4ff6313..d3567da 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -621,11 +621,15 @@ struct cifsInodeInfo {
/* BB add in lists for dirty pages i.e. write caching info for oplock */
struct list_head openFileList;
__u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */
- bool clientCanCacheRead; /* read oplock */
- bool clientCanCacheAll; /* read and writebehind oplock */
- bool delete_pending; /* DELETE_ON_CLOSE is set */
- bool invalid_mapping; /* pagecache is invalid */
+ bool clientCanCacheRead:1; /* read oplock */
+ bool clientCanCacheAll:1; /* read and writebehind oplock */
+ bool delete_pending:1; /* DELETE_ON_CLOSE is set */
+ bool invalid_mapping:1; /* pagecache is invalid */
+ bool btime_valid:1; /* stored creation time is valid */
+ bool uid_faked:1; /* true if i_uid is faked */
+ bool gid_faked:1; /* true if i_gid is faked */
unsigned long time; /* jiffies of last update of inode */
+ struct timespec btime; /* creation time */
u64 server_eof; /* current file size on server -- protected by i_lock */
u64 uniqueid; /* server inode number */
u64 createtime; /* creation time on server */
@@ -833,6 +837,9 @@ struct dfs_info3_param {
#define CIFS_FATTR_DELETE_PENDING 0x2
#define CIFS_FATTR_NEED_REVAL 0x4
#define CIFS_FATTR_INO_COLLISION 0x8
+#define CIFS_FATTR_WINATTRS_VALID 0x10 /* T if cf_btime and cf_cifsattrs valid */
+#define CIFS_FATTR_UID_FAKED 0x20 /* T if cf_uid is faked */
+#define CIFS_FATTR_GID_FAKED 0x40 /* T if cf_gid is faked */

struct cifs_fattr {
u32 cf_flags;
@@ -850,6 +857,7 @@ struct cifs_fattr {
struct timespec cf_atime;
struct timespec cf_mtime;
struct timespec cf_ctime;
+ struct timespec cf_btime;
};

static inline void free_dfs_info_param(struct dfs_info3_param *param)
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index d172c8e..d9e03ae 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -664,7 +664,7 @@ cifs_d_revalidate(struct dentry *direntry, struct nameidata *nd)
return -ECHILD;

if (direntry->d_inode) {
- if (cifs_revalidate_dentry(direntry))
+ if (cifs_revalidate_dentry(direntry, false, false))
return 0;
else {
/*
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 745da3d..662d5ce 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -135,13 +135,21 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr)
set_nlink(inode, fattr->cf_nlink);
inode->i_uid = fattr->cf_uid;
inode->i_gid = fattr->cf_gid;
+ if (fattr->cf_flags & CIFS_FATTR_UID_FAKED)
+ cifs_i->uid_faked = true;
+ if (fattr->cf_flags & CIFS_FATTR_GID_FAKED)
+ cifs_i->gid_faked = true;

/* if dynperm is set, don't clobber existing mode */
if (inode->i_state & I_NEW ||
!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_DYNPERM))
inode->i_mode = fattr->cf_mode;

- cifs_i->cifsAttrs = fattr->cf_cifsattrs;
+ if (fattr->cf_flags & CIFS_FATTR_WINATTRS_VALID) {
+ cifs_i->cifsAttrs = fattr->cf_cifsattrs;
+ cifs_i->btime = fattr->cf_btime;
+ cifs_i->btime_valid = true;
+ }

if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)
cifs_i->time = 0;
@@ -248,15 +256,19 @@ cifs_unix_basic_to_fattr(struct cifs_fattr *fattr, FILE_UNIX_BASIC_INFO *info,
break;
}

- if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID)
+ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID) {
fattr->cf_uid = cifs_sb->mnt_uid;
- else
+ fattr->cf_flags |= CIFS_FATTR_UID_FAKED;
+ } else {
fattr->cf_uid = le64_to_cpu(info->Uid);
+ }

- if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)
+ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID) {
fattr->cf_gid = cifs_sb->mnt_gid;
- else
+ fattr->cf_flags |= CIFS_FATTR_GID_FAKED;
+ } else {
fattr->cf_gid = le64_to_cpu(info->Gid);
+ }

fattr->cf_nlink = le64_to_cpu(info->Nlinks);
}
@@ -283,7 +295,8 @@ cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb)
fattr->cf_ctime = CURRENT_TIME;
fattr->cf_mtime = CURRENT_TIME;
fattr->cf_nlink = 2;
- fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL;
+ fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL |
+ CIFS_FATTR_UID_FAKED | CIFS_FATTR_GID_FAKED;
}

int cifs_get_file_info_unix(struct file *filp)
@@ -510,6 +523,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,
struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);

memset(fattr, 0, sizeof(*fattr));
+ fattr->cf_flags = CIFS_FATTR_WINATTRS_VALID;
fattr->cf_cifsattrs = le32_to_cpu(info->Attributes);
if (info->DeletePending)
fattr->cf_flags |= CIFS_FATTR_DELETE_PENDING;
@@ -521,6 +535,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,

fattr->cf_ctime = cifs_NTtimeToUnix(info->ChangeTime);
fattr->cf_mtime = cifs_NTtimeToUnix(info->LastWriteTime);
+ fattr->cf_btime = cifs_NTtimeToUnix(info->CreationTime);

if (adjust_tz) {
fattr->cf_ctime.tv_sec += tcon->ses->server->timeAdj;
@@ -1724,7 +1739,8 @@ int cifs_revalidate_file_attr(struct file *filp)
return rc;
}

-int cifs_revalidate_dentry_attr(struct dentry *dentry)
+int cifs_revalidate_dentry_attr(struct dentry *dentry,
+ bool want_extra_bits, bool force)
{
int xid;
int rc = 0;
@@ -1735,7 +1751,7 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry)
if (inode == NULL)
return -ENOENT;

- if (!cifs_inode_needs_reval(inode))
+ if (!force && !cifs_inode_needs_reval(inode))
return rc;

xid = GetXid();
@@ -1752,9 +1768,12 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry)
"%ld jiffies %ld", full_path, inode, inode->i_count.counter,
dentry, dentry->d_time, jiffies);

- if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext)
+ if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) {
rc = cifs_get_inode_info_unix(&inode, full_path, sb, xid);
- else
+ if (rc != 0)
+ goto out;
+ }
+ if (!cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext || want_extra_bits)
rc = cifs_get_inode_info(&inode, full_path, NULL, sb,
xid, NULL);

@@ -1779,12 +1798,13 @@ int cifs_revalidate_file(struct file *filp)
}

/* revalidate a dentry's inode attributes */
-int cifs_revalidate_dentry(struct dentry *dentry)
+int cifs_revalidate_dentry(struct dentry *dentry,
+ bool want_extra_bits, bool force)
{
int rc;
struct inode *inode = dentry->d_inode;

- rc = cifs_revalidate_dentry_attr(dentry);
+ rc = cifs_revalidate_dentry_attr(dentry, want_extra_bits, force);
if (rc)
return rc;

@@ -1796,11 +1816,30 @@ int cifs_revalidate_dentry(struct dentry *dentry)
int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat)
{
+ struct cifsInodeInfo *cifs_i = CIFS_I(dentry->d_inode);
struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb);
struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
struct inode *inode = dentry->d_inode;
+ unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC;
+ bool want_extra_bits = false;
+ u32 info, ioc = 0;
+ u32 attrs;
int rc;

+ if (cifs_i->uid_faked)
+ stat->request_mask &= ~XSTAT_UID;
+ if (cifs_i->gid_faked)
+ stat->request_mask &= ~XSTAT_GID;
+
+ if (stat->request_mask & XSTAT_BTIME && !cifs_i->btime_valid) {
+ want_extra_bits = true;
+ force = true;
+ }
+ if (stat->request_mask & XSTAT_IOC_FLAGS) {
+ want_extra_bits = true;
+ force = true;
+ }
+
/*
* We need to be sure that all dirty pages are written and the server
* has actual ctime, mtime and file length.
@@ -1814,13 +1853,14 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
}
}

- rc = cifs_revalidate_dentry_attr(dentry);
- if (rc)
- return rc;
+ if (force || stat->request_mask & XSTAT_BASIC_STATS) {
+ rc = cifs_revalidate_dentry(dentry, want_extra_bits, force);
+ if (rc)
+ return rc;
+ }

generic_fillattr(inode, stat);
stat->blksize = CIFS_MAX_MSGSIZE;
- stat->ino = CIFS_I(inode)->uniqueid;

/*
* If on a multiuser mount without unix extensions, and the admin hasn't
@@ -1834,7 +1874,53 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID))
stat->gid = current_fsgid();
}
- return rc;
+
+ info = XSTAT_INFO_REMOTE | XSTAT_INFO_NONSYSTEM_OWNERSHIP;
+#ifdef CONFIG_CIFS_ACL
+ info |= XSTAT_INFO_HAS_ACL;
+#endif
+
+ if (cifs_i->btime_valid) {
+ stat->btime = cifs_i->btime;
+ stat->result_mask |= XSTAT_BTIME;
+ }
+
+ /* We don't promise an inode number if we made one up */
+ stat->ino = cifs_i->uniqueid;
+ if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM))
+ stat->result_mask &= ~XSTAT_INO;
+
+ /*
+ * If on a multiuser mount without unix extensions, and the admin
+ * hasn't overridden them, set the ownership to the fsuid/fsgid of the
+ * current process.
+ */
+ if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MULTIUSER) &&
+ !tcon->unix_ext) {
+ if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID))
+ stat->uid = current_fsuid();
+ if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID))
+ stat->gid = current_fsgid();
+ }
+ if (cifs_i->uid_faked)
+ stat->result_mask &= ~XSTAT_UID;
+ if (cifs_i->gid_faked)
+ stat->result_mask &= ~XSTAT_GID;
+
+ attrs = cifs_i->cifsAttrs;
+ if (attrs & ATTR_HIDDEN) info |= XSTAT_INFO_HIDDEN;
+ if (attrs & ATTR_SYSTEM) info |= XSTAT_INFO_SYSTEM;
+ if (attrs & ATTR_ARCHIVE) info |= XSTAT_INFO_ARCHIVE;
+ if (attrs & ATTR_TEMPORARY) info |= XSTAT_INFO_TEMPORARY;
+ if (attrs & ATTR_REPARSE) info |= XSTAT_INFO_REPARSE_POINT;
+ if (attrs & ATTR_OFFLINE) info |= XSTAT_INFO_OFFLINE;
+ if (attrs & ATTR_ENCRYPTED) info |= XSTAT_INFO_ENCRYPTED;
+ stat->information |= info;
+
+ if (attrs & ATTR_READONLY) ioc |= FS_IMMUTABLE_FL;
+ if (attrs & ATTR_COMPRESSED) ioc |= FS_COMPR_FL;
+ stat->ioc_flags |= ioc;
+ return 0;
}

static int cifs_truncate_page(struct address_space *mapping, loff_t from)

2012-04-27 00:32:41

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDIyOjU3ICswMTAwLCBEYXZpZCBIb3dlbGxzIHdyb3RlOg0K
PiBNeWtsZWJ1c3QsIFRyb25kIDxUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4gd3JvdGU6DQo+
IA0KPiA+IFlvdSBhcmUgc3RpbGwgbm90IGV4cGxhaW5pbmcgd2h5IHRoZXkgbmVlZCB0byBrbm93
IHRoZSB2YWx1ZXMgYXQgYWxsPyBJZg0KPiA+IHRoZSB2YWx1ZXMgYXJlIGJvZ3VzLCB0aGVuIGRv
bid0IHJldHVybiB0aGVtLCBhbmQgZG9uJ3Qgc2V0IHRoZSBmbGFnDQo+ID4gdGhhdCBzYXlzIHRo
ZXkgYXJlIGJlaW5nIHJldHVybmVkLg0KPiB0aA0KPiBXaGF0IGlmIHRoZSB4c3RhdCgpIGFuZCBz
dHJ1Y3QgeHN0YXQgZXZlbnR1YWxseSBiZWNvbWVzIHdoYXQgdXNlcnNwYWNlIHVzZXMgYXMNCj4g
c3RhdCgpIChhcyBhIHdyYXBwZXIpIGFuZCBzdHJ1Y3Qgc3RhdCAoaWYgc3VjaCBhIHRoaW5nIGlz
IHBvc3NpYmxlIHdpdGggZ2xpYmMNCj4gdmVyc2lvbmluZyk/ICBEbyBvbGRlciBwcm9ncmFtcyB0
aGF0IHRoaW5rIHRoZXkncmUgdXNpbmcgc3RhdCgpIGFuZCBkb24ndCBrbm93DQo+IGFib3V0IHRo
ZSBleHRyYSBmaWVsZHMgYXZhaWxhYmxlIGV4cGVjdCB0byBzZWUgYSB1c2VmdWwgdmFsdWUgaW4g
c3RfaW5vPw0KDQpEb2VzIGl0IHJlYWxseSBtYXR0ZXIgd2hldGhlciBpdCBpcyB0aGUga2VybmVs
IG9yIHVzZXJsYW5kIHRoYXQgaXMNCnJlc3BvbnNpYmxlIGZvciBmYWtpbmcgdXAgaW5vZGUgbnVt
YmVycz8gSWYgdXNlcmxhbmQgd2FudHMgdG8gdXNlDQp4c3RhdCgpIGluIG9yZGVyIHRvIGZha2Ug
dXAgYSBzdGF0KCkgY2FsbCwgdGhlbiBpdCBnZXRzIHRvIHRha2UNCnJlc3BvbnNpYmlsaXR5IGZv
ciB0aGUgcmVzdWx0cy4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQg
bWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0
YXBwLmNvbQ0KDQo=

2012-04-26 23:25:19

by Nix

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 26 Apr 2012, Roland McGrath verbalised:

>> fileinfoat() perhaps? I think stat*at() is better, though, as people are
>> used to the stat function family.
>
> Names like that were all I had thought of when I said I hadn't thought of
> any good ones. ;-)

Quite. It's a garden-path function name. "What's a foat and why would I
want to put a file in one?"

--
NULL && (void)

2012-04-27 16:32:47

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Fri, Apr 27, 2012 at 10:10 AM, J. Bruce Fields <[email protected]> wrote:
> On Fri, Apr 27, 2012 at 11:13:06PM +1000, Dave Chinner wrote:
>> Right now it is, but there's ben patches in the past to introduce
>> project quotas to ext4. That didn't go far because it was done in a
>> way that was semantically different to XFS (for no reason that I
>> could understand) and nobody wanted two different sets of semantics
>> for the "same" feature. ?The most common use of project quotas is to
>> implement sub-tree quotas,
>
> (Though it's also useful as a way to do safe subtree NFS exports).

Quotas are very important to Samba (and Windows) admins.

See e.g.
http://www.samba.org/samba/docs/man/manpages-3/smbcquotas.1.html

But I would defer to Metze and others on the server side to see
whether XFS or the proposed ext4 quotas match the protocol
requirements which Samba has to support.

Does anyone know whether Samba can handle all of the remote quota
admin operations on Linux/XFS today (and local enforcement)?

--
Thanks,

Steve

2012-04-19 21:59:13

by Paul Eggert

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 04/19/2012 09:32 AM, Roland McGrath wrote:
> I have no comment on the functionality. But "xstat" is probably a poor
> choice of name.

In AIX 7.1 the (similar) function is called statxat instead of xstat.
The API isn't exactly the same, but it's the same basic idea.
Might be worth looking at, not merely to see whether the API
should be the same, but also to borrow good ideas even if not.

http://pic.dhe.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.basetechref/doc/basetrf2/statx.htm

2012-04-26 17:06:54

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDEyOjAzIC0wNTAwLCBTdGV2ZSBGcmVuY2ggd3JvdGU6DQo+
IE9uIFRodSwgQXByIDI2LCAyMDEyIGF0IDEyOjAwIFBNLCBNeWtsZWJ1c3QsIFRyb25kDQo+IDxU
cm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4gd3JvdGU6DQo+ID4gT24gVGh1LCAyMDEyLTA0LTI2
IGF0IDExOjU2IC0wNTAwLCBTdGV2ZSBGcmVuY2ggd3JvdGU6DQo+ID4+IE9uIFRodSwgQXByIDI2
LCAyMDEyIGF0IDEwOjI1IEFNLCBNeWtsZWJ1c3QsIFRyb25kDQo+ID4+IDxUcm9uZC5NeWtsZWJ1
c3RAbmV0YXBwLmNvbT4gd3JvdGU6DQo+ID4+ID4gT24gVGh1LCAyMDEyLTA0LTI2IGF0IDA5OjU0
IC0wNTAwLCBTdGV2ZSBGcmVuY2ggd3JvdGU6DQo+ID4+ID4+IE9uIFRodSwgQXByIDI2LCAyMDEy
IGF0IDk6MjUgQU0sIERhdmlkIEhvd2VsbHMgPGRob3dlbGxzQHJlZGhhdC5jb20+IHdyb3RlOg0K
PiA+PiA+PiA+IFN0ZXZlIEZyZW5jaCA8c21mcmVuY2hAZ21haWwuY29tPiB3cm90ZToNCj4gPj4g
Pj4gPg0KPiA+PiA+PiA+PiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gbWFrZSB0aGUgc3RhYmxlIHZz
IHZvbGF0aWxlIGlub2RlIG51bWJlciBhbiBhdHRyaWJ1dGUNCj4gPj4gPj4gPj4gb2YgdGhlIHZv
bHVtZSAgb3Igc29tZXRoaW5nIHJldHVybmVkIGJ5IHRoZSBwcm9wb3NlZCB4c3RhdD8NCj4gPj4g
Pj4gPg0KPiA+PiA+PiA+IEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IGEgc3RhYmxlIHZz
IGEgdm9sYXRpbGUgaW5vZGUgbnVtYmVyLg0KPiA+PiA+Pg0KPiA+PiA+PiBCb3RoIE5GUyBhbmQg
Q0lGUyAoYW5kIFNNQjIpIGNhbiByZXR1cm4gaW5vZGUgbnVtYmVycyBvciBlcXVpdmFsZW50DQo+
ID4+ID4+IHVuaXF1ZSBpZGVudGlmaWVyLCBidXQgaW4gdGhlIGNhc2Ugb2YgQ0lGUyBzb21lIG9s
ZCBzZXJ2ZXJzIGRvbid0IHN1cHBvcnQgdGhlDQo+ID4+ID4+IGNhbGxzIHdoaWNoIHJldHVybiBp
bm9kZSBudW1iZXJzIChvciBkb24ndCByZXR1cm4gdGhlbSBmb3IgYWxsIGZpbGUgc3lzdGVtDQo+
ID4+ID4+IHR5cGVzLCBXaW5kb3dzIEZBVD8pIHNvIGluIHRoZXNlIGNhc2VzIGNpZnMgaGFzIHRv
IGNyZWF0ZSBpbm9kZQ0KPiA+PiA+PiBudW1iZXJzIG9uIHRoZSBmbHkNCj4gPj4gPj4gb24gdGhl
IGNsaWVudC4gICBpbm9kZSBudW1iZXJzIGNyZWF0ZWQgb24gdGhlIGNsaWVudCBhcmUgbm90ICJz
dGFibGUiIHRoZXkNCj4gPj4gPj4gY2FuIGNoYW5nZSBvbiB1bm1vdW50L3JlbW91bnQgKHdoaWNo
IGNhbiBjYXVzZSBwcm9ibGVtcyBmb3IgYmFja3VwDQo+ID4+ID4+IGFwcGxpY2F0aW9ucykuDQo+
ID4+ID4+DQo+ID4+ID4+IFNpbWlsYXJseSBORlN2NCBkb2VzIG5vdCByZXF1aXJlIHRoYXQgc2Vy
dmVycyBhbHdheXMgcmV0dXJuIHN0YWJsZSBpbm9kZSBudW1iZXJzDQo+ID4+ID4+ICh0aGF0IHdp
bGwgbmV2ZXIgY2hhbmdlKSBhbmQgaW50cm9kdWNlZCBhIGNvbmNlcHQgb2YgInZvbGF0aWxlIGZp
bGUgaGFuZGxlLiINCj4gPj4gPj4gV2UgaGF2ZSBydW4gaW50byB0aGlzIGluIHR3byBjYXNlcyAo
dGhlcmUgYXJlIHByb2JhYmx5IG1vcmUpIC0NCj4gPj4gPj4gU3BlY2lhbGl6ZWQgTkZTIHNlcnZl
cnMNCj4gPj4gPj4gZm9yIEhQQyB3aGljaCBkZWFsIHdpdGggbG90cyBvZiB0cmFuc2llbnQgaW5v
ZGVzLCBhbmQgc2Vjb25kIHRob3NlIGZvciBzZXJ2ZXJzDQo+ID4+ID4+IHdoaWNoIGJhc2UgdGhl
cmUgaW5vZGUgbnVtYmVyIG9uIHBhdGggKFdpbmRvd3MgTkZTPykuICBTZWUNCj4gPj4gPj4gaHR0
cDovL2RvY3Mub3JhY2xlLmNvbS9jZC9FMTkwODItMDEvODE5LTE2MzQvcmZzcmVmZXItMTM3L2lu
ZGV4Lmh0bWwNCj4gPj4gPj4gb3IgdGhlIE5GU3Y0IFJGQy4NCj4gPj4gPj4NCj4gPj4gPj4gQmFz
aWNhbGx5IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIGl0IGlzIHdvcnRoIHJlcG9ydGluZyBhIGZs
YWcgb24gdGhlDQo+ID4+ID4+IGNhbGwgd2hpY2ggcmV0dXJucw0KPiA+PiA+PiB0aGUgaW5vZGUg
bnVtYmVyIHRvIGluZGljYXRlIHRoYXQgdGhlIGlub2RlIG51bWJlciBpcyAic3RhYmxlIiAod291
bGQgbm90IGNoYW5nZQ0KPiA+PiA+PiBvbiByZWJvb3Qgb3IgcmVjb25uZWN0aW9uKSBvciAidm9s
YXRpbGUuIiAgICBTaW5jZSB0aGUgbWFqb3JpdHkgb2YgTkZTDQo+ID4+ID4+IGFuZCBTTUIyIHNl
cnZlcnMNCj4gPj4gPj4gY2FuIHJldHVybiBzdGFibGUgaW5vZGUgbnVtYmVycywgSSBkb24ndCBm
ZWVsIHN0cm9uZ2x5IGFib3V0IHRoZSBuZWVkDQo+ID4+ID4+IGZvciBhbiBpbmRpY2F0b3INCj4g
Pj4gPj4gb2YgInN0YWJsZSIgdnMuICJ2b2xhdGlsZSIgYnV0IEkgbWVudGlvbiBpdCBiZWNhdXNl
IGJhY2t1cCBhbmQNCj4gPj4gPj4gbWlncmF0aW9uIGFwcGxpY2F0aW9ucw0KPiA+PiA+PiBtZW50
aW9uIHRoaXMgKGlmIGlub2RlIG51bWJlcnMgYXJlIHZvbGF0aWxlLCB0aGV5IG1heSBoYXZlIHRv
IGNoZWNrDQo+ID4+ID4+IGZvciBoYXJkbGlua3MgZGlmZmVyZW50bHkNCj4gPj4gPj4gZm9yIGV4
YW1wbGUpDQo+ID4+ID4NCj4gPj4gPiBJIGRvbid0IHVuZGVyc3RhbmQuIElmIHRoZSBmaWxlc3lz
dGVtIGRvZXNuJ3Qgc3VwcG9ydCByZWFsIGlub2RlDQo+ID4+ID4gbnVtYmVycywgdGhlbiB3aHkg
cmVwb3J0IHRoZW0gYXQgYWxsPyBXaGF0IHVzZSB3b3VsZCBhbiBhcHBsaWNhdGlvbiBoYXZlDQo+
ID4+ID4gZm9yIGFuIGlub2RlIG51bWJlciB0aGF0IGNhbid0IGJlIHVzZWQgdG8gaWRlbnRpZnkg
aGFyZCBsaW5rZWQgZmlsZXM/DQo+ID4+DQo+ID4+IFdlbGwgLi4uIHlvdSBoYXZlIHRvIGhhdmUg
YW4gaW5vZGUgbnVtYmVyIG9uIHRoZSBMaW51eCBjbGllbnQgc2lkZSBldmVuIGlmDQo+ID4+IHRo
ZSBzZXJ2ZXIgZG9lc24ndCByZXBvcnQgdGhlbSAob3IgaGFzIGEgYnVnIGFuZCByZXBvcnRzIGR1
cGxpY2F0ZXMpLg0KPiA+PiBJZiB5b3UgY2FuJ3QgdGVsbCBoYXJkbGlua2VkIGZpbGVzIGFwYXJ0
IGZpeCB0aGUgc2VydmVyIChidXQgaW4gdGhlDQo+ID4+IGNhc2VzIHdoZXJlIHRoZSBmaWxlIHN5
c3RlbXMgaGFzIHRoaXMgcHJvYmxlbSB0aGUgc2VydmVyIGRvZXNuJ3QgdXN1YWxseQ0KPiA+PiBz
dXBwb3J0IGhhcmRsaW5rcyBlaXRoZXIpLg0KPiA+Pg0KPiA+PiBJZiB0aGUgc2VydmVyJ3MgZmls
ZSBzeXN0ZW0gaW50ZXJuYWwgc3RydWN0dXJlcyBkb24ndCBzdXBwb3J0IHJlYWwgaW5vZGUNCj4g
Pj4gbnVtYmVycyAoc3VjaCBhcyBGQVQgb3IgYSByYW1kaXNrKSB0aGVuIGl0IGVpdGhlciBoYXMg
dG8gbWFrZSB0aGVtDQo+ID4+IHVwIGJhc2VkIG9uIHNvbWV0aGluZyBsaWtlIHBhdGggbmFtZSBv
ciBzb21lIG90aGVyIGF0dHJpYnV0ZSBvZiB0aGUNCj4gPj4gZmlsZSBvbiBkaXNrLg0KPiA+Pg0K
PiA+PiBTZXJ2ZXJzIGxpa2UgTmV0QXBwIGlzIHdoZXJlIHRoaXMgZ2V0cyBpbnRlcmVzdGluZyAt
IGZvciBjaWZzIGUuZy4gbGV2ZWwgMTAwOQ0KPiA+PiBxdWVyeSBmaWxlIGluZm8gaXMgdXNlZCB0
byBxdWVyeV9maWxlX2ludGVybmFsX2luZm8gKHRoZSBpbm9kZSBudW1iZXIpIGJ1dA0KPiA+PiB3
aGF0IGlmIHRoZSBzZXJ2ZXIgY2FuIG5vdCByZXBvcnQgaW5vZGUgbnVtYmVycyAoZHVlIHRvIGEg
YnVnKSBpbg0KPiA+PiBhbGwgY2FzZXMuDQo+ID4NCj4gPiBSaWdodCwgYnV0IG5vbmUgb2YgdGhp
cyBleHBsYWlucyB3aHkgd2UgbmVlZCB0byByZXBvcnQgdGhlc2UgYm9ndXMgaW5vZGUNCj4gPiBu
dW1iZXJzIHRvIHRoZSBhcHBsaWNhdGlvbiBpbiB0aGUgeHN0YXQoKSByZXBseS4NCj4gDQo+IHRo
ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbiAoYmFja3VwKSB3b3VsZCBuZWVk
IHRvIGtub3cNCj4gdGhhdCB0aGUgaW5vZGUgbnVtYmVycyBhcmUgYm9ndXMgYW5kIGZyb20gbXkg
Y29udmVyc2F0aW9ucyB3aXRoDQo+IGd1eXMgd3JpdGluZyBiYWNrdXAgc29mdHdhcmUgaXQgc2Vl
bXMgdGhhdCBzdWNoIGRhdGEgaXMgdXNlZnVsIHRvIHRoZW0uDQoNCllvdSBhcmUgc3RpbGwgbm90
IGV4cGxhaW5pbmcgd2h5IHRoZXkgbmVlZCB0byBrbm93IHRoZSB2YWx1ZXMgYXQgYWxsPyBJZg0K
dGhlIHZhbHVlcyBhcmUgYm9ndXMsIHRoZW4gZG9uJ3QgcmV0dXJuIHRoZW0sIGFuZCBkb24ndCBz
ZXQgdGhlIGZsYWcNCnRoYXQgc2F5cyB0aGV5IGFyZSBiZWluZyByZXR1cm5lZC4NCg0KVHJvbmQN
Cg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpO
ZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=

2012-04-27 09:39:50

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Dave Chinner <[email protected]> wrote:

> 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?

I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly
which flags you're talking about. The question, though, is what will actually
make use of these flags? Will it just be XFS tools or are they something that
a GUI might make use of?

Either you can add some of them to the ioc flags (which may be impractical, I
grant you) or we'd have to add an arbitrary fs-type specific field and specify
the host fs (the provision of which might not be a bad idea in and of itself)
to tell userspace how to interpret them.

> 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...

Yeah... Not representable by one number. You'd have to unset a flag to say
you were providing this information.

However, providing a whole bunch of hints about I/O characteristics is probably
beyond this syscall - especially if it isn't constant over the length of a
file. That's specialist knowledge that most applications don't need to know.
Having a generic way to retrieve it, though, may be a good idea.

OTOH, there's plenty of uncommitted space, so if we can condense the hints down
to something small, we could perhaps add it later - but from your paragraph
above, it doesn't sound like it'll be small.

> 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....

Is this an XFS only thing? If so, can it be generalised?

David

2012-04-26 17:00:38

[permalink] [raw]

Subject: Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

On Thu, Apr 26, 2012 at 8:47 AM, David Howells <[email protected]> wrote:
> Steve French <[email protected]> wrote:
>
>> This patch reminds me of a question on time stamps - how can an
>> application query the time granularity ie sb_s_time_gran for a mount
>> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
>> nanosecond for others etc.)
>
> Ummm... ?In what context? ?With the proposed xstat() interface it will be
> provided.

great (although I thought it would be "stat -f" property).

--
Thanks,

Steve

2012-04-26 18:22:06

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

> Roland McGrath <[email protected]> wrote:
>
> > statx seems like a better family of names. I also think it's worthwhile to
> > see if the interface can be made to more closely match the AIX precedent.
>
> I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very
> closely, at least from a syscall interface point of view.

OK. It was just worth a look.

Thanks,
Roland

2012-04-24 22:08:29

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Tue, Apr 24, 2012 at 4:29 PM, J. Bruce Fields <[email protected]> wrote:
> On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
>> Add a pair of system calls to make extended file stats available, including
>> file creation time, inode version and data version where available through the
>> underlying filesystem.
>>
>> The idea was initially proposed as a set of xattrs that could be retrieved with
>> getxattr(), but the general preferance proved to be for new syscalls with an
>> extended stat structure.
>>
>> This has a number of uses:
>>
>> ?(1) Creation time: The SMB protocol carries the creation time, which could be
>> ? ? ?exported by Samba, which will in turn help CIFS make use of FS-Cache as
>> ? ? ?that can be used for coherency data.
>>
>> ? ? ?This is also specified in NFSv4 as a recommended attribute and could be
>> ? ? ?exported by NFSD [Steve French].
>>
>> ?(2) Lightweight stat: Ask for just those details of interest, and allow a
>> ? ? ?netfs (such as NFS) to approximate anything not of interest, possibly
>> ? ? ?without going to the server [Trond Myklebust, Ulrich Drepper].
>>
>> ?(3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its
>> ? ? ?cached attributes are up to date [Trond Myklebust].
>>
>> ?(4) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd
>> ? ? ?Schubert].
>>
>> ?(5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar].
>>
>> ? ? ?Can also be used to modify fill_post_wcc() in NFSD which retrieves
>> ? ? ?i_version directly, but has just called vfs_getattr(). ?It could get it
>> ? ? ?from the kstat struct if it used vfs_xgetattr() instead.
>>
>> ?(6) BSD stat compatibility: Including more fields from the BSD stat such as
>> ? ? ?creation time (st_btime) and inode generation number (st_gen) [Jeremy
>> ? ? ?Allison, Bernd Schubert].
>>
>> ?(7) Extra coherency data may be useful in making backups [Andreas Dilger].
>>
>> ?(8) Allow the filesystem to indicate what it can/cannot provide: A filesystem
>> ? ? ?can now say it doesn't support a standard stat feature if that isn't
>> ? ? ?available, so if, for instance, inode numbers or UIDs don't exist...
>>
>> ?(9) Make the fields a consistent size on all arches and make them large.
>>
>> (10) Store a 16-byte volume ID in the superblock that can be returned in struct
>> ? ? ?xstat [Steve French].
>>
>> (11) Include granularity fields in the time data to indicate the granularity of
>> ? ? ?each of the times (NFSv4 time_delta) [Steve French].
>
> It looks like you're including this with *each* time? ?But surely
> there's no filesystem with different granularity (say) for ctime than
> for mtime. ?Also, nfsd will want only one time_delta, not one for each
> time.
>
> Note also we need to document carefully what this means: I think it
> should be the granularity that the filesystem is capable of
> representing, but people are sometimes surprised to find out that the
> actual time source is usually more coarse-grained than that.

I also would prefer that we simply treat the time granularity as part
of the superblock (mounted volume) ie returned on fstat rather than on
every stat of the filesystem. For cifs mounts we could conceivably
have different time granularity (1 or 2 second) on mounts to old
servers rather than 100 nanoseconds.

--
Thanks,

Steve

2012-04-19 16:40:43

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

I have no comment on the functionality. But "xstat" is probably a poor
choice of name. There is precedent for that function name with different
meaning in the userland APIs. (It's a moderately useless meaning inherited
from SVR4, but regardless overloading a name previously used is unwise.)

Thanks,
Roland

2012-04-28 00:38:38

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 09:22:04PM -0600, Andreas Dilger wrote:
> On 2012-04-26, at 7:06 PM, Dave Chinner wrote:
> > 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 (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?
>
> I'm sympathetic to your cause, but I don't want this to degrade into
> the same morass that it did last time when every attribute under the
> sun was added to the call.

Understood, which is why I'm not asking for everything under the sun
to be supported. I'm more interested in finding the useful subset of
information that a typical application might make use of.

> The intent is to replace the stat() call
> with something that can avoid overhead on filesystems for which some
> attributes are expensive, and that applications may not need. Some
> common attributes were added that are used by multiple filesystems.
>
> If it is too filesystem-specific, and there is little possibility
> that these attributes will be usable on other filesystems, then it
> should remain a filesystem specific ioctl() call.

Right, that's why I didn't mention the real-time bits, the
filestream allocation bits, or other things that are tightly bound
to the way XFS works....

> If you can make
> a case that these attributes have value on a few other filesystems,
> and applications are reasonably likely to be able to use them, and
> their addition does not make the API overly complex, then suggest
> away.

Exactly my thoughts ;)

> > 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...
>
> There is already "optimal IO size" that the application can use,
> how do the geometry hints differ?

Have a look at how XFS overloads stat.st_blksize depending on the
filesystem and inode config. It's amazingly convoluted, and based on
a combination of filesystem geometry, inode bits and mount options:

xfs_vn_getattr()
....
if (XFS_IS_REALTIME_INODE(ip)) {
/*
* If the file blocks are being allocated from a
* realtime volume, then return the inode's realtime
* extent size or the realtime volume's extent size.
*/
stat->blksize =
xfs_get_extsz_hint(ip) << mp->m_sb.sb_blocklog;
} else
stat->blksize = xfs_preferred_iosize(mp);
......

xfs_extlen_t
xfs_get_extsz_hint(
struct xfs_inode *ip)
{
if ((ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) && ip->i_d.di_extsize)
return ip->i_d.di_extsize;
if (XFS_IS_REALTIME_INODE(ip))
return ip->i_mount->m_sb.sb_rextsize;
return 0;
}

....

static inline unsigned long
xfs_preferred_iosize(xfs_mount_t *mp)
{
if (mp->m_flags & XFS_MOUNT_COMPAT_IOSIZE)
return PAGE_CACHE_SIZE;
return (mp->m_swidth ?
(mp->m_swidth << mp->m_sb.sb_blocklog) :
((mp->m_flags & XFS_MOUNT_DFLT_IOSIZE) ?
(1 << (int)MAX(mp->m_readio_log, mp->m_writeio_log)) :
PAGE_CACHE_SIZE));
}

All of that can be exported as 4 parameters for normal files:

allocation block size (extent size hint)
minimum io size (PAGE_CACHE_SIZE)
preferred minimum IO size (mp->m_readio_log/mp->m_writeio_log)
best aligned IO size (stripe width)

And for realtime files it's a bit different because of the
block-based bitmap allocator it uses:

allocation block size (extent size hint)
minimum io size (PAGE_CACHE_SIZE)
preferred minimum IO size (extent size hint)
best aligned IO size (some multiple of extent size hint)

> Userspace is able to handle
> st_blksize of several MB in size without problems, and any sane
> application will do the IO sized + aligned on multiples of this.

Actually, some applications still have problems with that. That's
the reason we only expose stripe widths in st_blksize when a mount
option is set. Stripe widths are known to get into the tens of MB,
and applications using st_blksize for memory allocation of IO
buffers tend to get into trouble with those.

That's why I'd prefer specific optimal IO hints - we don't have to
overload st_blksize with lots of meanings to pass what is relatively
trivial information back to the application.

Cheers,

Dave.
--
Dave Chinner
[email protected]

2012-04-26 18:24:03

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

> Interesting. I wasn't intending to provide both statx() and statxat()
> variants, just the latter, in which case I'd've though that -at suffix is
> redundant.

It's certainly fine to provide only *at flavors for any new syscall, IMHO.
The * case is always just a simple degenerate case of *at, and libc can
trivially provide the simpler user API as well using the *at syscall.

But please keep the uniformity that everything taking a descriptor and AT_*
flags is named *at.

Thanks,
Roland

2012-04-24 21:29:37

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
> Add a pair of system calls to make extended file stats available, including
> file creation time, inode version and data version where available through the
> underlying filesystem.
>
> The idea was initially proposed as a set of xattrs that could be retrieved with
> getxattr(), but the general preferance proved to be for new syscalls with an
> extended stat structure.
>
> This has a number of uses:
>
> (1) Creation time: The SMB protocol carries the creation time, which could be
> exported by Samba, which will in turn help CIFS make use of FS-Cache as
> that can be used for coherency data.
>
> This is also specified in NFSv4 as a recommended attribute and could be
> exported by NFSD [Steve French].
>
> (2) Lightweight stat: Ask for just those details of interest, and allow a
> netfs (such as NFS) to approximate anything not of interest, possibly
> without going to the server [Trond Myklebust, Ulrich Drepper].
>
> (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its
> cached attributes are up to date [Trond Myklebust].
>
> (4) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd
> Schubert].
>
> (5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar].
>
> Can also be used to modify fill_post_wcc() in NFSD which retrieves
> i_version directly, but has just called vfs_getattr(). It could get it
> from the kstat struct if it used vfs_xgetattr() instead.
>
> (6) BSD stat compatibility: Including more fields from the BSD stat such as
> creation time (st_btime) and inode generation number (st_gen) [Jeremy
> Allison, Bernd Schubert].
>
> (7) Extra coherency data may be useful in making backups [Andreas Dilger].
>
> (8) Allow the filesystem to indicate what it can/cannot provide: A filesystem
> can now say it doesn't support a standard stat feature if that isn't
> available, so if, for instance, inode numbers or UIDs don't exist...
>
> (9) Make the fields a consistent size on all arches and make them large.
>
> (10) Store a 16-byte volume ID in the superblock that can be returned in struct
> xstat [Steve French].
>
> (11) Include granularity fields in the time data to indicate the granularity of
> each of the times (NFSv4 time_delta) [Steve French].

It looks like you're including this with *each* time? But surely
there's no filesystem with different granularity (say) for ctime than
for mtime. Also, nfsd will want only one time_delta, not one for each
time.

Note also we need to document carefully what this means: I think it
should be the granularity that the filesystem is capable of
representing, but people are sometimes surprised to find out that the
actual time source is usually more coarse-grained than that.

--b.

>
> (12) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.
>
> (13) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
> Michael Kerrisk].
>
> (14) Spare space, request flags and information flags are provided for future
> expansion.
>
>
> The following structures are defined for the use of these new system calls:
>
> struct xstat_dev {
> uint32_t major, minor;
> };
>
> struct xstat_time {
> uint64_t tv_sec;
> uint32_t tv_nsec;
> uint32_t tv_granularity;
> };
>
> struct xstat {
> uint32_t st_mask;
> uint32_t st_mode;
> uint32_t st_nlink;
> uint32_t st_uid;
> uint32_t st_gid;
> uint32_t st_information;
> uint32_t st_ioc_flags;
> uint32_t st_blksize;
> struct xstat_dev st_rdev;
> struct xstat_dev st_dev;
> struct xstat_time st_atime;
> struct xstat_time st_btime;
> struct xstat_time st_ctime;
> struct xstat_time st_mtime;
> uint64_t st_ino;
> uint64_t st_size;
> uint64_t st_blocks;
> uint64_t st_gen;
> uint64_t st_version;
> uint8_t st_volume_id[16];
> uint64_t __spares[11];
> };
>
> where st_information is local system information about the file, st_btime is
> the file creation time, st_gen is the inode generation (i_generation),
> st_data_version is the data version number (i_version), st_ioc_flags is the
> flags from FS_IOC_GETFLAGS, st_volume_id is where the volume identified is
> stored, st_result_mask is a bitmask indicating the data provided and __spares[]
> are where as-yet undefined fields can be placed.
>
> The defined bits in request_mask and st_mask are:
>
> XSTAT_MODE Want/got st_mode
> XSTAT_NLINK Want/got st_nlink
> XSTAT_UID Want/got st_uid
> XSTAT_GID Want/got st_gid
> XSTAT_RDEV Want/got st_rdev
> XSTAT_ATIME Want/got st_atime
> XSTAT_MTIME Want/got st_mtime
> XSTAT_CTIME Want/got st_ctime
> XSTAT_INO Want/got st_ino
> XSTAT_SIZE Want/got st_size
> XSTAT_BLOCKS Want/got st_blocks
> XSTAT_BASIC_STATS [The stuff in the normal stat struct]
> XSTAT_IOC_FLAGS Want/got FS_IOC_GETFLAGS
> XSTAT_BTIME Want/got st_btime
> XSTAT_GEN Want/got st_gen
> XSTAT_VERSION Want/got st_data_version
> XSTAT_VOLUME_ID Want/got st_volume_id
> XSTAT_ALL_STATS [All currently available stuff]
>
> The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra flags
> that might be supplied by the filesystem. Note that Ext4 returns flags outside
> of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS. Should
> {EXT4,FS}_FL_USER_VISIBLE be extended to cover them? Or should the extra flags
> be suppressed?
>
> The defined bits in the st_information field give local system data on a file,
> how it is accessed, where it is and what it does:
>
> XSTAT_INFO_ENCRYPTED File is encrypted
> XSTAT_INFO_TEMPORARY File is temporary (NTFS/CIFS/deleted)
> XSTAT_INFO_FABRICATED File was made up by filesystem
> XSTAT_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs)
> XSTAT_INFO_REMOTE File is remote
> XSTAT_INFO_OFFLINE File is offline (CIFS)
> XSTAT_INFO_AUTOMOUNT Dir is automount trigger
> XSTAT_INFO_AUTODIR Dir provides unlisted automounts
> XSTAT_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details
> XSTAT_INFO_HAS_ACL File has an ACL of some sort
> XSTAT_INFO_REPARSE_POINT File is reparse point (NTFS/CIFS)
> XSTAT_INFO_HIDDEN File is marked hidden (DOS+)
> XSTAT_INFO_SYSTEM File is marked system (DOS+)
> XSTAT_INFO_ARCHIVE File is marked archive (DOS+)
>
> These are for the use of GUI tools that might want to mark files specially,
> depending on what they are. I've tried not to provide overlap with
> st_ioc_flags where something usable exists there. Should Hidden, System and
> Archive flags be associated with ioc_flags, perhaps with ioc_flags extended to
> 64-bits?
>
>
> The system calls are:
>
> ssize_t ret = xstat(int dfd,
> const char *filename,
> unsigned int flags,
> unsigned int mask,
> struct xstat *buffer);
>
> ssize_t ret = fxstat(unsigned fd,
> unsigned int flags,
> unsigned int mask,
> struct xstat *buffer);
>
>
> The dfd, filename, flags and fd parameters indicate the file to query. There
> is no equivalent of lstat() as that can be emulated with xstat() by passing
> AT_SYMLINK_NOFOLLOW in flags.
>
> AT_FORCE_ATTR_SYNC can also be set in flags. This will require a network
> filesystem to synchronise its attributes with the server.
>
> mask is a bitmask indicating the fields in struct xstat that are of interest to
> the caller. The user should set this to XSTAT__BASIC_STATS to get the
> basic set returned by stat().
>
> Should there just be one xstat() syscall that does fxstat() if filename is NULL?
>
> The fields in struct xstat come in a number of classes:
>
> (0) st_dev, st_blksize, st_information.
>
> These are local data and are always available.
>
> (1) st_mode, st_nlinks, st_uid, st_gid, st_[amc]time, st_ino, st_size,
> st_blocks.
>
> These will be returned whether the caller asks for them or not. The
> corresponding bits in result_mask will be set to indicate their presence.
>
> If the caller didn't ask for them, then they may be approximated. For
> example, NFS won't waste any time updating them from the server, unless as
> a byproduct of updating something requested.
>
> If the values don't actually exist for the underlying object (such as UID
> or GID on a DOS file), then the bit won't be set in the result_mask, even
> if the caller asked for the value and the returned value will be a
> fabrication.
>
> (2) st_rdev.
>
> As for class (1), but this won't be returned if the file is not a blockdev
> or chardev. The bit will be cleared if the value is not returned.
>
> (3) File creation time (st_btime), inode generation (st_gen), data version
> (st_version), volume_id (st_volume_id) and inode flags (st_ioc_flags).
>
> These will be returned if available whether the caller asked for them or
> not. The corresponding bits in result_mask will be set or cleared as
> appropriate to indicate their presence.
>
> If the caller didn't ask for them, then they may be approximated. For
> example, NFS won't waste any time updating them from the server, unless
> as a byproduct of updating something requested.
>
> At the moment, this will only work on x86_64 and i386 as it requires system
> calls to be wired up.
>
>
> =======
> TESTING
> =======
>
> The following test program can be used to test the xstat system call:
>
> /* Test the xstat() system call
> *
> * Copyright (C) 2010 Red Hat, Inc. All Rights Reserved.
> * Written by David Howells ([email protected])
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public Licence
> * as published by the Free Software Foundation; either version
> * 2 of the Licence, or (at your option) any later version.
> */
>
> #define _GNU_SOURCE
> #define _ATFILE_SOURCE
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <time.h>
> #include <sys/syscall.h>
> #include <sys/stat.h>
> #include <sys/types.h>
>
> #define AT_NO_AUTOMOUNT 0x800
> #define AT_FORCE_ATTR_SYNC 0x2000
>
> #define XSTAT_MODE 0x00000001U
> #define XSTAT_NLINK 0x00000002U
> #define XSTAT_UID 0x00000004U
> #define XSTAT_GID 0x00000008U
> #define XSTAT_RDEV 0x00000010U
> #define XSTAT_ATIME 0x00000020U
> #define XSTAT_MTIME 0x00000040U
> #define XSTAT_CTIME 0x00000080U
> #define XSTAT_INO 0x00000100U
> #define XSTAT_SIZE 0x00000200U
> #define XSTAT_BLOCKS 0x00000400U
> #define XSTAT_BASIC_STATS 0x000007ffU
> #define XSTAT_BTIME 0x00000800U
> #define XSTAT_GEN 0x00001000U
> #define XSTAT_VERSION 0x00002000U
> #define XSTAT_IOC_FLAGS 0x00004000U
> #define XSTAT_VOLUME_ID 0x00008000U
> #define XSTAT_ALL_STATS 0x0000ffffU
>
> struct xstat_dev {
> uint32_t major;
> uint32_t minor;
> };
>
> struct xstat_time {
> uint64_t tv_sec;
> uint32_t tv_nsec;
> uint32_t tv_granularity;
> };
>
> struct xstat {
> uint32_t st_mask;
> uint32_t st_mode;
> uint32_t st_nlink;
> uint32_t st_uid;
> uint32_t st_gid;
> uint32_t st_information;
> uint32_t st_ioc_flags;
> uint32_t st_blksize;
> struct xstat_dev st_rdev;
> struct xstat_dev st_dev;
> struct xstat_time st_atim;
> struct xstat_time st_btim;
> struct xstat_time st_ctim;
> struct xstat_time st_mtim;
> uint64_t st_ino;
> uint64_t st_size;
> uint64_t st_blksize;
> uint64_t st_blocks;
> uint64_t st_gen;
> uint64_t st_version;
> uint64_t st_volume_id[16];
> uint64_t st_spares[11];
> };
>
> #define XSTAT_INFO_ENCRYPTED 0x00000001U
> #define XSTAT_INFO_TEMPORARY 0x00000002U
> #define XSTAT_INFO_FABRICATED 0x00000004U
> #define XSTAT_INFO_KERNEL_API 0x00000008U
> #define XSTAT_INFO_REMOTE 0x00000010U
> #define XSTAT_INFO_OFFLINE 0x00000020U
> #define XSTAT_INFO_AUTOMOUNT 0x00000040U
> #define XSTAT_INFO_AUTODIR 0x00000080U
> #define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U
> #define XSTAT_INFO_HAS_ACL 0x00000200U
> #define XSTAT_INFO_REPARSE_POINT 0x00000400U
> #define XSTAT_INFO_HIDDEN 0x00000800U
> #define XSTAT_INFO_SYSTEM 0x00001000U
> #define XSTAT_INFO_ARCHIVE 0x00002000U
>
> #define __NR_xstat 312
> #define __NR_fxstat 313
>
> static __attribute__((unused))
> ssize_t xstat(int dfd, const char *filename, unsigned flags,
> unsigned int mask, struct xstat *buffer)
> {
> return syscall(__NR_xstat, dfd, filename, flags, mask, buffer);
> }
>
> static __attribute__((unused))
> ssize_t fxstat(int fd, unsigned flags,
> unsigned int mask, struct xstat *buffer)
> {
> return syscall(__NR_fxstat, fd, flags, mask, buffer);
> }
>
> static void print_time(const char *field, const struct xstat_time *xstm)
> {
> struct tm tm;
> time_t tim;
> char buffer[100];
> int len;
>
> tim = xstm->tv_sec;
> if (!localtime_r(&tim, &tm)) {
> perror("localtime_r");
> exit(1);
> }
> len = strftime(buffer, 100, "%F %T", &tm);
> if (len == 0) {
> perror("strftime");
> exit(1);
> }
> printf("%s", field);
> fwrite(buffer, 1, len, stdout);
> printf(".%09u", xstm->tv_nsec);
> len = strftime(buffer, 100, "%z", &tm);
> if (len == 0) {
> perror("strftime2");
> exit(1);
> }
> fwrite(buffer, 1, len, stdout);
> printf("\n");
> }
>
> static void dump_xstat(struct xstat *xst)
> {
> char buffer[256], ft;
>
> printf("results=%x\n", xst->st_mask);
>
> printf(" ");
> if (xst->st_mask & XSTAT_SIZE)
> printf(" Size: %-15llu", (unsigned long long) xst->st_size);
> if (xst->st_mask & XSTAT_BLOCKS)
> printf(" Blocks: %-10llu", (unsigned long long) xst->st_blocks);
> printf(" IO Block: %-6llu ", (unsigned long long) xst->st_blksize);
> if (xst->st_mask & XSTAT_MODE) {
> switch (xst->st_mode & S_IFMT) {
> case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break;
> case S_IFCHR: printf(" character special file\n"); ft = 'c'; break;
> case S_IFDIR: printf(" directory\n"); ft = 'd'; break;
> case S_IFBLK: printf(" block special file\n"); ft = 'b'; break;
> case S_IFREG: printf(" regular file\n"); ft = '-'; break;
> case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break;
> case S_IFSOCK: printf(" socket\n"); ft = 's'; break;
> default:
> printf("unknown type (%o)\n", xst->st_mode & S_IFMT);
> ft = '?';
> break;
> }
> }
>
> sprintf(buffer, "%02x:%02x", xst->st_dev.major, xst->st_dev.minor);
> printf("Device: %-15s", buffer);
> if (xst->st_mask & XSTAT_INO)
> printf(" Inode: %-11llu", (unsigned long long) xst->st_ino);
> if (xst->st_mask & XSTAT_SIZE)
> printf(" Links: %-5u", xst->st_nlink);
> if (xst->st_mask & XSTAT_RDEV)
> printf(" Device type: %u,%u",
> xst->st_rdev.major, xst->st_rdev.minor);
> printf("\n");
>
> if (xst->st_mask & XSTAT_MODE)
> printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ",
> xst->st_mode & 07777,
> ft,
> xst->st_mode & S_IRUSR ? 'r' : '-',
> xst->st_mode & S_IWUSR ? 'w' : '-',
> xst->st_mode & S_IXUSR ? 'x' : '-',
> xst->st_mode & S_IRGRP ? 'r' : '-',
> xst->st_mode & S_IWGRP ? 'w' : '-',
> xst->st_mode & S_IXGRP ? 'x' : '-',
> xst->st_mode & S_IROTH ? 'r' : '-',
> xst->st_mode & S_IWOTH ? 'w' : '-',
> xst->st_mode & S_IXOTH ? 'x' : '-');
> if (xst->st_mask & XSTAT_UID)
> printf("Uid: %d \n", xst->st_uid);
> if (xst->st_mask & XSTAT_GID)
> printf("Gid: %u\n", xst->st_gid);
>
> if (xst->st_mask & XSTAT_ATIME)
> print_time("Access: ", &xst->st_atim);
> if (xst->st_mask & XSTAT_MTIME)
> print_time("Modify: ", &xst->st_mtim);
> if (xst->st_mask & XSTAT_CTIME)
> print_time("Change: ", &xst->st_ctim);
> if (xst->st_mask & XSTAT_BTIME)
> print_time("Create: ", &xst->st_btim);
>
> if (xst->st_mask & XSTAT_GEN)
> printf("Inode version: %llxh\n", (unsigned long long) xst->st_gen);
> if (xst->st_mask & XSTAT_VERSION)
> printf("Data version: %llxh\n", (unsigned long long) xst->st_version);
>
> if (xst->st_mask & XSTAT_IOC_FLAGS) {
> unsigned char bits;
> int loop, byte;
>
> static char flag_representation[32 + 1] =
> /* FS_IOC_GETFLAGS flags: */
> "????????" /* 31-24 0x00000000-ff000000 */
> "????ehTD" /* 23-16 0x00000000-00ff0000 */
> "tj?IE?XZ" /* 15- 8 0x00000000-0000ff00 */
> "AdaiScus" /* 7- 0 0x00000000-000000ff */
> ;
>
> printf("Inode flags: %08x (", xst->st_ioc_flags);
> for (byte = 32 - 8; byte >= 0; byte -= 8) {
> bits = xst->st_ioc_flags >> byte;
> for (loop = 7; loop >= 0; loop--) {
> int bit = byte + loop;
>
> if (bits & 0x80)
> putchar(flag_representation[31 - bit]);
> else
> putchar('-');
> bits <<= 1;
> }
> if (byte)
> putchar(' ');
> }
> printf(")\n");
> }
>
> if (xst->st_information) {
> unsigned char bits;
> int loop, byte;
>
> static char info_representation[32 + 1] =
> /* XSTAT_INFO_ flags: */
> "????????" /* 31-24 0x00000000-ff000000 */
> "????????" /* 23-16 0x00000000-00ff0000 */
> "??ASHRan" /* 15- 8 0x00000000-0000ff00 */
> "dmorkfte" /* 7- 0 0x00000000-000000ff */
> ;
>
> printf("Information: %08x (", xst->st_information);
> for (byte = 32 - 8; byte >= 0; byte -= 8) {
> bits = xst->st_information >> byte;
> for (loop = 7; loop >= 0; loop--) {
> int bit = byte + loop;
>
> if (bits & 0x80)
> putchar(info_representation[31 - bit]);
> else
> putchar('-');
> bits <<= 1;
> }
> if (byte)
> putchar(' ');
> }
> printf(")\n");
> }
>
> if (xst->st_mask & XSTAT_VOLUME_ID) {
> int loop;
> printf("Volume ID: ");
> for (loop = 0; loop < sizeof(xst->st_volume_id); loop++) {
> printf("%02x", xst->st_volume_id[loop]);
> if (loop == 7)
> printf("-");
> }
> printf("\n");
> }
> }
>
> void dump_hex(unsigned long long *data, int from, int to)
> {
> unsigned offset, print_offset = 1, col = 0;
>
> from /= 8;
> to = (to + 7) / 8;
>
> for (offset = from; offset < to; offset++) {
> if (print_offset) {
> printf("%04x: ", offset * 8);
> print_offset = 0;
> }
> printf("%016llx", data[offset]);
> col++;
> if ((col & 3) == 0) {
> printf("\n");
> print_offset = 1;
> } else {
> printf(" ");
> }
> }
>
> if (!print_offset)
> printf("\n");
> }
>
> int main(int argc, char **argv)
> {
> struct xstat xst;
> int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW;
>
> unsigned int mask = XSTAT_ALL_STATS;
>
> for (argv++; *argv; argv++) {
> if (strcmp(*argv, "-F") == 0) {
> atflag |= AT_FORCE_ATTR_SYNC;
> continue;
> }
> if (strcmp(*argv, "-L") == 0) {
> atflag &= ~AT_SYMLINK_NOFOLLOW;
> continue;
> }
> if (strcmp(*argv, "-O") == 0) {
> mask &= ~XSTAT_BASIC_STATS;
> continue;
> }
> if (strcmp(*argv, "-A") == 0) {
> atflag |= AT_NO_AUTOMOUNT;
> continue;
> }
> if (strcmp(*argv, "-R") == 0) {
> raw = 1;
> continue;
> }
>
> memset(&xst, 0xbf, sizeof(xst));
> ret = xstat(AT_FDCWD, *argv, atflag, mask, &xst);
> printf("xstat(%s) = %d\n", *argv, ret);
> if (ret < 0) {
> perror(*argv);
> exit(1);
> }
>
> if (raw)
> dump_hex((unsigned long long *)&xst, 0, sizeof(xst));
>
> dump_xstat(&xst);
> }
> return 0;
> }
>
> Just compile and run, passing it paths to the files you want to examine:
>
> [root@andromeda ~]# /tmp/xstat /proc/$$
> xstat(/proc/2074) = 160
> results=47ef
> Size: 0 Blocks: 0 IO Block: 1024 directory
> Device: 00:03 Inode: 9072 Links: 7
> Access: (0555/dr-xr-xr-x) Uid: 0
> Gid: 0
> Access: 2010-07-14 16:50:46.609336272+0100
> Modify: 2010-07-14 16:50:46.609336272+0100
> Change: 2010-07-14 16:50:46.609336272+0100
> Inode flags: 0000000100000000 (-------- -------- -------- -------S -------- -------- -------- --------)
> [root@andromeda ~]# /tmp/xstat /afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm
> xstat(/afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm) = 160
> results=77ef
> Size: 5413882 Blocks: 0 IO Block: 4096 regular file
> Device: 00:15 Inode: 2288 Links: 1
> Access: (0644/-rw-r--r--) Uid: 75338
> Gid: 0
> Access: 2008-11-05 19:47:22.000000000+0000
> Modify: 2008-11-05 19:47:22.000000000+0000
> Change: 2008-11-05 19:47:22.000000000+0000
> Inode version: 795h
> Data version: 2h
> Inode flags: 0000000800000000 (-------- -------- -------- ----r--- -------- -------- -------- --------)
>
> Signed-off-by: David Howells <[email protected]>
> ---
>
> arch/x86/syscalls/syscall_32.tbl | 2
> arch/x86/syscalls/syscall_64.tbl | 2
> fs/stat.c | 350 +++++++++++++++++++++++++++++++++++---
> include/linux/fcntl.h | 1
> include/linux/fs.h | 4
> include/linux/stat.h | 126 +++++++++++++-
> include/linux/syscalls.h | 7 +
> 7 files changed, 461 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
> index 29f9f05..980eb5a 100644
> --- a/arch/x86/syscalls/syscall_32.tbl
> +++ b/arch/x86/syscalls/syscall_32.tbl
> @@ -355,3 +355,5 @@
> 346 i386 setns sys_setns
> 347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv
> 348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev
> +349 i386 xstat sys_xstat
> +350 i386 fxstat sys_fxstat
> diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
> index dd29a9e..7ae24bb 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -318,6 +318,8 @@
> 309 common getcpu sys_getcpu
> 310 64 process_vm_readv sys_process_vm_readv
> 311 64 process_vm_writev sys_process_vm_writev
> +312 common xstat sys_xstat
> +313 common fxstat sys_fxstat
> #
> # x32-specific system call numbers start at 512 to avoid cache impact
> # for native 64-bit operation.
> diff --git a/fs/stat.c b/fs/stat.c
> index c733dc5..af3ef33 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -18,8 +18,20 @@
> #include <asm/uaccess.h>
> #include <asm/unistd.h>
>
> +/**
> + * generic_fillattr - Fill in the basic attributes from the inode struct
> + * @inode: Inode to use as the source
> + * @stat: Where to fill in the attributes
> + *
> + * Fill in the basic attributes in the kstat structure from data that's to be
> + * found on the VFS inode structure. This is the default if no getattr inode
> + * operation is supplied.
> + */
> void generic_fillattr(struct inode *inode, struct kstat *stat)
> {
> + struct super_block *sb = inode->i_sb;
> + u32 x;
> +
> stat->dev = inode->i_sb->s_dev;
> stat->ino = inode->i_ino;
> stat->mode = inode->i_mode;
> @@ -27,17 +39,61 @@ void generic_fillattr(struct inode *inode, struct kstat *stat)
> stat->uid = inode->i_uid;
> stat->gid = inode->i_gid;
> stat->rdev = inode->i_rdev;
> - stat->size = i_size_read(inode);
> - stat->atime = inode->i_atime;
> stat->mtime = inode->i_mtime;
> stat->ctime = inode->i_ctime;
> - stat->blksize = (1 << inode->i_blkbits);
> + stat->size = i_size_read(inode);
> stat->blocks = inode->i_blocks;
> -}
> + stat->blksize = (1 << inode->i_blkbits);
>
> + stat->result_mask |= XSTAT_BASIC_STATS & ~XSTAT_RDEV;
> + if (IS_NOATIME(inode))
> + stat->result_mask &= ~XSTAT_ATIME;
> + else
> + stat->atime = inode->i_atime;
> +
> + if (S_ISREG(stat->mode) && stat->nlink == 0)
> + stat->information |= XSTAT_INFO_TEMPORARY;
> + if (IS_AUTOMOUNT(inode))
> + stat->information |= XSTAT_INFO_AUTOMOUNT;
> + if (IS_POSIXACL(inode))
> + stat->information |= XSTAT_INFO_HAS_ACL;
> +
> + /* if unset, assume 1s granularity */
> + stat->tv_granularity = sb->s_time_gran ?: 1000000000U;
> +
> + if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode)))
> + stat->result_mask |= XSTAT_RDEV;
> +
> + x = ((u32*)&stat->volume_id)[0] = ((u32*)&sb->s_volume_id)[0];
> + x |= ((u32*)&stat->volume_id)[1] = ((u32*)&sb->s_volume_id)[1];
> + x |= ((u32*)&stat->volume_id)[2] = ((u32*)&sb->s_volume_id)[2];
> + x |= ((u32*)&stat->volume_id)[3] = ((u32*)&sb->s_volume_id)[3];
> + if (x)
> + stat->result_mask |= XSTAT_VOLUME_ID;
> +}
> EXPORT_SYMBOL(generic_fillattr);
>
> -int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> +/**
> + * vfs_xgetattr - Get the basic and extra attributes of a file
> + * @mnt: The mountpoint to which the dentry belongs
> + * @dentry: The file of interest
> + * @stat: Where to return the statistics
> + *
> + * Ask the filesystem for a file's attributes. The caller must have preset
> + * stat->request_mask and stat->query_flags to indicate what they want.
> + *
> + * If the file is remote, the filesystem can be forced to update the attributes
> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags.
> + *
> + * Bits must have been set in stat->request_mask to indicate which attributes
> + * the caller wants retrieving. Any such attribute not requested may be
> + * returned anyway, but the value may be approximate, and, if remote, may not
> + * have been synchronised with the server.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry,
> + struct kstat *stat)
> {
> struct inode *inode = dentry->d_inode;
> int retval;
> @@ -46,64 +102,184 @@ int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> if (retval)
> return retval;
>
> + stat->result_mask = 0;
> + stat->information = 0;
> + stat->ioc_flags = 0;
> if (inode->i_op->getattr)
> return inode->i_op->getattr(mnt, dentry, stat);
>
> generic_fillattr(inode, stat);
> return 0;
> }
> +EXPORT_SYMBOL(vfs_xgetattr);
>
> +/**
> + * vfs_getattr - Get the basic attributes of a file
> + * @mnt: The mountpoint to which the dentry belongs
> + * @dentry: The file of interest
> + * @stat: Where to return the statistics
> + *
> + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't
> + * forced to update its files from the backing store. Only the basic set of
> + * attributes will be retrieved; anyone wanting more must use vfs_getxattr(),
> + * as must anyone who wants to force attributes to be sync'd with the server.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> +{
> + stat->query_flags = 0;
> + stat->request_mask = XSTAT_BASIC_STATS;
> + return vfs_xgetattr(mnt, dentry, stat);
> +}
> EXPORT_SYMBOL(vfs_getattr);
>
> -int vfs_fstat(unsigned int fd, struct kstat *stat)
> +/**
> + * vfs_fxstat - Get basic and extra attributes by file descriptor
> + * @fd: The file descriptor refering to the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xgetattr(). The main difference is
> + * that it uses a file descriptor to determine the file location.
> + *
> + * The caller must have preset stat->query_flags and stat->request_mask as for
> + * vfs_xgetattr().
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_fxstat(unsigned int fd, struct kstat *stat)
> {
> struct file *f = fget(fd);
> int error = -EBADF;
>
> + if (stat->query_flags & ~KSTAT_QUERY_FLAGS)
> + return -EINVAL;
> if (f) {
> - error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat);
> + error = vfs_xgetattr(f->f_path.mnt, f->f_path.dentry, stat);
> fput(f);
> }
> return error;
> }
> +EXPORT_SYMBOL(vfs_fxstat);
> +
> +/**
> + * vfs_fstat - Get basic attributes by file descriptor
> + * @fd: The file descriptor refering to the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_getattr(). The main difference is
> + * that it uses a file descriptor to determine the file location.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_fstat(unsigned int fd, struct kstat *stat)
> +{
> + stat->query_flags = 0;
> + stat->request_mask = XSTAT_BASIC_STATS;
> + return vfs_fxstat(fd, stat);
> +}
> EXPORT_SYMBOL(vfs_fstat);
>
> -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
> - int flag)
> +/**
> + * vfs_xstat - Get basic and extra attributes by filename
> + * @dfd: A file descriptor representing the base dir for a relative filename
> + * @filename: The name of the file of interest
> + * @flags: Flags to control the query
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xgetattr(). The main difference is
> + * that it uses a filename and base directory to determine the file location.
> + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a
> + * symlink at the given name from being referenced.
> + *
> + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The
> + * flags are also used to load up stat->query_flags.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_xstat(int dfd, const char __user *filename, int flags,
> + struct kstat *stat)
> {
> struct path path;
> - int error = -EINVAL;
> - int lookup_flags = 0;
> + int error, lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
>
> - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
> - AT_EMPTY_PATH)) != 0)
> - goto out;
> + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
> + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
> + return -EINVAL;
>
> - if (!(flag & AT_SYMLINK_NOFOLLOW))
> - lookup_flags |= LOOKUP_FOLLOW;
> - if (flag & AT_EMPTY_PATH)
> + if (flags & AT_SYMLINK_NOFOLLOW)
> + lookup_flags &= ~LOOKUP_FOLLOW;
> + if (flags & AT_NO_AUTOMOUNT)
> + lookup_flags &= ~LOOKUP_AUTOMOUNT;
> + if (flags & AT_EMPTY_PATH)
> lookup_flags |= LOOKUP_EMPTY;
>
> + stat->query_flags = flags & KSTAT_QUERY_FLAGS;
> error = user_path_at(dfd, filename, lookup_flags, &path);
> - if (error)
> - goto out;
> -
> - error = vfs_getattr(path.mnt, path.dentry, stat);
> - path_put(&path);
> -out:
> + if (!error) {
> + error = vfs_xgetattr(path.mnt, path.dentry, stat);
> + path_put(&path);
> + }
> return error;
> }
> +EXPORT_SYMBOL(vfs_xstat);
> +
> +/**
> + * vfs_fstatat - Get basic attributes by filename
> + * @dfd: A file descriptor representing the base dir for a relative filename
> + * @filename: The name of the file of interest
> + * @flags: Flags to control the query
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xstat(). The difference is that it
> + * preselects basic stats only. The flags are used to load up
> + * stat->query_flags in addition to indicating symlink handling during path
> + * resolution.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
> + int flags)
> +{
> + stat->request_mask = XSTAT_BASIC_STATS;
> + return vfs_xstat(dfd, filename, flags, stat);
> +}
> EXPORT_SYMBOL(vfs_fstatat);
>
> -int vfs_stat(const char __user *name, struct kstat *stat)
> +/**
> + * vfs_stat - Get basic attributes by filename
> + * @filename: The name of the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xstat(). The difference is that it
> + * preselects basic stats only, terminal symlinks are followed regardless and a
> + * remote filesystem can't be forced to query the server. If such is desired,
> + * vfs_xstat() should be used instead.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> +int vfs_stat(const char __user *filename, struct kstat *stat)
> {
> - return vfs_fstatat(AT_FDCWD, name, stat, 0);
> + stat->request_mask = XSTAT_BASIC_STATS;
> + return vfs_xstat(AT_FDCWD, filename, 0, stat);
> }
> EXPORT_SYMBOL(vfs_stat);
>
> +/**
> + * vfs_stat - Get basic attributes by filename, without following terminal symlink
> + * @filename: The name of the file of interest
> + * @stat: The result structure to fill in.
> + *
> + * This function is a wrapper around vfs_xstat(). The difference is that it
> + * preselects basic stats only, terminal symlinks are note followed regardless
> + * and a remote filesystem can't be forced to query the server. If such is
> + * desired, vfs_xstat() should be used instead.
> + *
> + * 0 will be returned on success, and a -ve error code if unsuccessful.
> + */
> int vfs_lstat(const char __user *name, struct kstat *stat)
> {
> - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW);
> + return vfs_xstat(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat);
> }
> EXPORT_SYMBOL(vfs_lstat);
>
> @@ -118,7 +294,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
> {
> static int warncount = 5;
> struct __old_kernel_stat tmp;
> -
> +
> if (warncount > 0) {
> warncount--;
> printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n",
> @@ -143,7 +319,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
> #if BITS_PER_LONG == 32
> if (stat->size > MAX_NON_LFS)
> return -EOVERFLOW;
> -#endif
> +#endif
> tmp.st_size = stat->size;
> tmp.st_atime = stat->atime.tv_sec;
> tmp.st_mtime = stat->mtime.tv_sec;
> @@ -225,7 +401,7 @@ static int cp_new_stat(struct kstat *stat, struct stat __user *statbuf)
> #if BITS_PER_LONG == 32
> if (stat->size > MAX_NON_LFS)
> return -EOVERFLOW;
> -#endif
> +#endif
> tmp.st_size = stat->size;
> tmp.st_atime = stat->atime.tv_sec;
> tmp.st_mtime = stat->mtime.tv_sec;
> @@ -412,6 +588,122 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
> }
> #endif /* __ARCH_WANT_STAT64 */
>
> +/*
> + * Get the xstat parameters if supplied
> + */
> +static int xstat_get_params(unsigned int mask, struct xstat __user *buffer,
> + struct kstat *stat)
> +{
> + memset(stat, 0xde, sizeof(*stat)); // DEBUGGING
> +
> + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer)))
> + return -EFAULT;
> +
> + stat->request_mask = mask & XSTAT_ALL_STATS;
> + stat->result_mask = 0;
> + return 0;
> +}
> +
> +/*
> + * Set the xstat results.
> + *
> + * If the buffer size was 0, we just return the size of the buffer needed to
> + * return the full result.
> + *
> + * If bufsize indicates a buffer of insufficient size to hold the full result,
> + * we return -E2BIG.
> + *
> + * Otherwise we copy the extended stats to userspace and return the amount of
> + * data written into the buffer (or -EFAULT).
> + */
> +static long xstat_set_result(struct kstat *stat, struct xstat __user *buffer)
> +{
> + u32 mask = stat->result_mask, gran = stat->tv_granularity;
> +
> +#define __put_timestamp(kts, uts) ( \
> + __put_user(kts.tv_sec, uts.tv_sec ) || \
> + __put_user(kts.tv_nsec, uts.tv_nsec ) || \
> + __put_user(gran, uts.tv_granularity ))
> +
> + /* clear out anything we're not returning */
> + if (!(mask & XSTAT_IOC_FLAGS))
> + stat->ioc_flags = 0;
> + if (!(mask & XSTAT_BTIME))
> + memset(&stat->btime, 0, sizeof(stat->btime));
> + if (!(mask & XSTAT_GEN))
> + stat->gen = 0;
> + if (!(mask & XSTAT_VERSION))
> + stat->version = 0;
> + if (!(mask & XSTAT_VOLUME_ID))
> + memset(&stat->volume_id, 0, sizeof(stat->volume_id));
> +
> + /* transfer the results */
> + if (__put_user(mask, &buffer->st_mask ) ||
> + __put_user(stat->mode, &buffer->st_mode ) ||
> + __put_user(stat->nlink, &buffer->st_nlink ) ||
> + __put_user(stat->uid, &buffer->st_uid ) ||
> + __put_user(stat->gid, &buffer->st_gid ) ||
> + __put_user(stat->information, &buffer->st_information ) ||
> + __put_user(stat->ioc_flags, &buffer->st_ioc_flags ) ||
> + __put_user(stat->blksize, &buffer->st_blksize ) ||
> + __put_user(MAJOR(stat->rdev), &buffer->st_rdev.major ) ||
> + __put_user(MINOR(stat->rdev), &buffer->st_rdev.minor ) ||
> + __put_user(MAJOR(stat->dev), &buffer->st_dev.major ) ||
> + __put_user(MINOR(stat->dev), &buffer->st_dev.minor ) ||
> + __put_timestamp(stat->atime, &buffer->st_atime ) ||
> + __put_timestamp(stat->btime, &buffer->st_btime ) ||
> + __put_timestamp(stat->ctime, &buffer->st_ctime ) ||
> + __put_timestamp(stat->mtime, &buffer->st_mtime ) ||
> + __put_user(stat->ino, &buffer->st_ino ) ||
> + __put_user(stat->size, &buffer->st_size ) ||
> + __put_user(stat->blocks, &buffer->st_blocks ) ||
> + __put_user(stat->gen, &buffer->st_gen ) ||
> + __put_user(stat->version, &buffer->st_version ) ||
> + __copy_to_user(&buffer->st_volume_id, &stat->volume_id,
> + sizeof(buffer->st_volume_id) ) ||
> + __clear_user(&buffer->__spares, sizeof(buffer->__spares)))
> + return -EFAULT;
> + return 0;
> +}
> +
> +/*
> + * System call to get extended stats by path
> + */
> +SYSCALL_DEFINE5(xstat,
> + int, dfd, const char __user *, filename, unsigned, flags,
> + unsigned int, mask, struct xstat __user *, buffer)
> +{
> + struct kstat stat;
> + int error;
> +
> + error = xstat_get_params(mask, buffer, &stat);
> + if (error != 0)
> + return error;
> + error = vfs_xstat(dfd, filename, flags, &stat);
> + if (error)
> + return error;
> + return xstat_set_result(&stat, buffer);
> +}
> +
> +/*
> + * System call to get extended stats by file descriptor
> + */
> +SYSCALL_DEFINE4(fxstat, unsigned int, fd, unsigned int, flags,
> + unsigned int, mask, struct xstat __user *, buffer)
> +{
> + struct kstat stat;
> + int error;
> +
> + error = xstat_get_params(mask, buffer, &stat);
> + if (error < 0)
> + return error;
> + stat.query_flags = flags;
> + error = vfs_fxstat(fd, &stat);
> + if (error)
> + return error;
> + return xstat_set_result(&stat, buffer);
> +}
> +
> /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
> void __inode_add_bytes(struct inode *inode, loff_t bytes)
> {
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index f550f89..faa9e5d 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -47,6 +47,7 @@
> #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
> #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */
> #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */
> +#define AT_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */
>
> #ifdef __KERNEL__
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8de6755..ec6c62e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1467,6 +1467,7 @@ struct super_block {
>
> char s_id[32]; /* Informational name */
> u8 s_uuid[16]; /* UUID */
> + unsigned char s_volume_id[16]; /* Volume identifier */
>
> void *s_fs_info; /* Filesystem private info */
> unsigned int s_max_links;
> @@ -2470,6 +2471,7 @@ extern const struct inode_operations page_symlink_inode_operations;
> extern int generic_readlink(struct dentry *, char __user *, int);
> extern void generic_fillattr(struct inode *, struct kstat *);
> extern int vfs_getattr(struct vfsmount *, struct dentry *, struct kstat *);
> +extern int vfs_xgetattr(struct vfsmount *, struct dentry *, struct kstat *);
> void __inode_add_bytes(struct inode *inode, loff_t bytes);
> void inode_add_bytes(struct inode *inode, loff_t bytes);
> void inode_sub_bytes(struct inode *inode, loff_t bytes);
> @@ -2482,6 +2484,8 @@ extern int vfs_stat(const char __user *, struct kstat *);
> extern int vfs_lstat(const char __user *, struct kstat *);
> extern int vfs_fstat(unsigned int, struct kstat *);
> extern int vfs_fstatat(int , const char __user *, struct kstat *, int);
> +extern int vfs_xstat(int, const char __user *, int, struct kstat *);
> +extern int vfs_xfstat(unsigned int, struct kstat *);
>
> extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
> unsigned long arg);
> diff --git a/include/linux/stat.h b/include/linux/stat.h
> index 611c398..0ff561a 100644
> --- a/include/linux/stat.h
> +++ b/include/linux/stat.h
> @@ -3,6 +3,7 @@
>
> #ifdef __KERNEL__
>
> +#include <linux/types.h>
> #include <asm/stat.h>
>
> #endif
> @@ -46,6 +47,117 @@
>
> #endif
>
> +/*
> + * Query request/result mask
> + *
> + * Bits should be set in request_mask to request particular items when calling
> + * xstat() or fxstat().
> + *
> + * The bits in st_mask may or may not be set upon return, in part depending on
> + * what was set in the mask argument:
> + *
> + * - if not available at all, the bit will be cleared before returning and the
> + * field will be cleared; otherwise,
> + *
> + * - if AT_FORCE_ATTR_SYNC is set, then the datum will be synchronised to the
> + * server and the field and bit will be set on return; otherwise,
> + *
> + * - if explicitly requested, the datum will be synchronised to a server or
> + * other medium if out of date before being returned, and the bit will be set
> + * on return; otherwise,
> + *
> + * - if not requested, but available in approximate form without any effort, it
> + * will be filled in anyway, and the bit will be set upon return (it might
> + * not be up to date, however, and no attempt will be made to synchronise the
> + * internal state first); otherwise,
> + *
> + * - the field and the bit will be cleared before returning.
> + *
> + * Items in XSTAT_BASIC_STATS may be marked unavailable on return, but they
> + * will have a value installed for compatibility purposes so that stat() and
> + * co. can be emulated in userspace.
> + */
> +#define XSTAT_MODE 0x00000001U /* want/got st_mode */
> +#define XSTAT_NLINK 0x00000002U /* want/got st_nlink */
> +#define XSTAT_UID 0x00000004U /* want/got st_uid */
> +#define XSTAT_GID 0x00000008U /* want/got st_gid */
> +#define XSTAT_RDEV 0x00000010U /* want/got st_rdev */
> +#define XSTAT_ATIME 0x00000020U /* want/got st_atime */
> +#define XSTAT_MTIME 0x00000040U /* want/got st_mtime */
> +#define XSTAT_CTIME 0x00000080U /* want/got st_ctime */
> +#define XSTAT_INO 0x00000100U /* want/got st_ino */
> +#define XSTAT_SIZE 0x00000200U /* want/got st_size */
> +#define XSTAT_BLOCKS 0x00000400U /* want/got st_blocks */
> +#define XSTAT_BASIC_STATS 0x000007ffU /* the stuff in the normal stat struct */
> +#define XSTAT_IOC_FLAGS 0x00000800U /* want/got FS_IOC_GETFLAGS */
> +#define XSTAT_BTIME 0x00001000U /* want/got st_btime */
> +#define XSTAT_GEN 0x00002000U /* want/got st_gen */
> +#define XSTAT_VERSION 0x00004000U /* want/got st_version */
> +#define XSTAT_VOLUME_ID 0x00008000U /* want/got st_volume_id */
> +#define XSTAT_ALL_STATS 0x0000ffffU /* all supported stats */
> +
> +/*
> + * Extended stat structures
> + */
> +struct xstat_dev {
> + uint32_t major, minor;
> +};
> +
> +struct xstat_time {
> + int64_t tv_sec;
> + uint32_t tv_nsec;
> + uint32_t tv_granularity; /* time granularity (in nS) */
> +};
> +
> +struct xstat {
> + uint32_t st_mask; /* what results were written */
> + uint32_t st_mode; /* file mode */
> + uint32_t st_nlink; /* number of hard links */
> + uint32_t st_uid; /* user ID of owner */
> + uint32_t st_gid; /* group ID of owner */
> + uint32_t st_information; /* information about the file */
> + uint32_t st_ioc_flags; /* as FS_IOC_GETFLAGS */
> + uint32_t st_blksize; /* optimal size for filesystem I/O */
> + struct xstat_dev st_rdev; /* device ID of special file */
> + struct xstat_dev st_dev; /* ID of device containing file */
> + struct xstat_time st_atime; /* last access time */
> + struct xstat_time st_btime; /* file creation time */
> + struct xstat_time st_ctime; /* last attribute change time */
> + struct xstat_time st_mtime; /* last data modification time */
> + uint64_t st_ino; /* inode number */
> + uint64_t st_size; /* file size */
> + uint64_t st_blocks; /* number of 512-byte blocks allocated */
> + uint64_t st_gen; /* inode generation number */
> + uint64_t st_version; /* data version number */
> + uint8_t st_volume_id[16]; /* volume identifier */
> + uint64_t __spares[11]; /* spare space for future expansion */
> +};
> +
> +/*
> + * Flags to be found in st_information
> + *
> + * These give information about the features or the state of a file that might
> + * be of use to ordinary userspace programs such as GUIs or ls rather than
> + * specialised tools.
> + *
> + * Additional information may be found in st_ioc_flags and we try not to
> + * overlap with it.
> + */
> +#define XSTAT_INFO_ENCRYPTED 0x00000001U /* File is encrypted */
> +#define XSTAT_INFO_TEMPORARY 0x00000002U /* File is temporary (NTFS/CIFS) */
> +#define XSTAT_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */
> +#define XSTAT_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */
> +#define XSTAT_INFO_REMOTE 0x00000010U /* File is remote */
> +#define XSTAT_INFO_OFFLINE 0x00000020U /* File is offline (CIFS) */
> +#define XSTAT_INFO_AUTOMOUNT 0x00000040U /* Dir is automount trigger */
> +#define XSTAT_INFO_AUTODIR 0x00000080U /* Dir provides unlisted automounts */
> +#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U /* File has non-system ownership details */
> +#define XSTAT_INFO_HAS_ACL 0x00000200U /* File has an ACL of some sort */
> +#define XSTAT_INFO_REPARSE_POINT 0x00000400U /* File is reparse point (NTFS/CIFS) */
> +#define XSTAT_INFO_HIDDEN 0x00000800U /* File is marked hidden (DOS+) */
> +#define XSTAT_INFO_SYSTEM 0x00001000U /* File is marked system (DOS+) */
> +#define XSTAT_INFO_ARCHIVE 0x00002000U /* File is marked archive (DOS+) */
> +
> #ifdef __KERNEL__
> #define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO)
> #define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO)
> @@ -60,6 +172,12 @@
> #include <linux/time.h>
>
> struct kstat {
> + u32 query_flags; /* operational flags */
> +#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC)
> + u32 request_mask; /* what fields the user asked for */
> + u32 result_mask; /* what fields the user got */
> + u32 information;
> + u32 ioc_flags; /* inode flags (FS_IOC_GETFLAGS) */
> u64 ino;
> dev_t dev;
> umode_t mode;
> @@ -67,14 +185,18 @@ struct kstat {
> uid_t uid;
> gid_t gid;
> dev_t rdev;
> + unsigned int tv_granularity; /* granularity of times (in nS) */
> loff_t size;
> - struct timespec atime;
> + struct timespec atime;
> struct timespec mtime;
> struct timespec ctime;
> + struct timespec btime; /* file creation time */
> unsigned long blksize;
> unsigned long long blocks;
> + u64 gen; /* inode generation */
> + u64 version; /* data version */
> + unsigned char volume_id[16]; /* volume identifier */
> };
>
> #endif
> -
> #endif
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 3de3acb..ff9f8d9 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -45,6 +45,8 @@ struct shmid_ds;
> struct sockaddr;
> struct stat;
> struct stat64;
> +struct xstat_parameters;
> +struct xstat;
> struct statfs;
> struct statfs64;
> struct __sysctl_args;
> @@ -858,4 +860,9 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
> unsigned long riovcnt,
> unsigned long flags);
>
> +asmlinkage long sys_xstat(int dfd, const char __user *path, unsigned flags,
> + unsigned mask, struct xstat __user *buffer);
> +asmlinkage long sys_fxstat(unsigned fd, unsigned flags,
> + unsigned mask, struct xstat __user *buffer);
> +
> #endif
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2012-04-19 16:03:56

[permalink] [raw]

Subject: Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

This patch reminds me of a question on time stamps - how can an
application query the time granularity ie sb_s_time_gran for a mount
(e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
nanosecond for others etc.)

On Thu, Apr 19, 2012 at 9:06 AM, David Howells <[email protected]> wrote:
> Return extended attributes from the Ext4 filesystem. ?This includes the
> following:
>
> ?(1) The inode creation time (i_crtime) as i_btime.
>
> ?(2) The inode i_generation as i_gen if not the root directory.
>
> ?(3) The inode i_version as st_data_version if a file with I_VERSION set or a
> ? ? directory.
>
> ?(4) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS).
>
> Signed-off-by: David Howells <[email protected]>
> ---
>
> ?fs/ext4/ext4.h ? ?| ? ?2 ++
> ?fs/ext4/file.c ? ?| ? ?2 +-
> ?fs/ext4/inode.c ? | ? 32 +++++++++++++++++++++++++++++---
> ?fs/ext4/namei.c ? | ? ?2 ++
> ?fs/ext4/super.c ? | ? ?1 +
> ?fs/ext4/symlink.c | ? ?2 ++
> ?6 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index ab2594a..81806da 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1899,6 +1899,8 @@ extern int ?ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct kstat *stat);
> ?extern void ext4_evict_inode(struct inode *);
> ?extern void ext4_clear_inode(struct inode *);
> +extern int ?ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct kstat *stat);
> ?extern int ?ext4_sync_inode(handle_t *, struct inode *);
> ?extern void ext4_dirty_inode(struct inode *, int);
> ?extern int ext4_change_inode_journal_flag(struct inode *, int);
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index cb70f18..ae8654c 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -249,7 +249,7 @@ const struct file_operations ext4_file_operations = {
>
> ?const struct inode_operations ext4_file_inode_operations = {
> ? ? ? ?.setattr ? ? ? ?= ext4_setattr,
> - ? ? ? .getattr ? ? ? ?= ext4_getattr,
> + ? ? ? .getattr ? ? ? ?= ext4_file_getattr,
> ?#ifdef CONFIG_EXT4_FS_XATTR
> ? ? ? ?.setxattr ? ? ? = generic_setxattr,
> ? ? ? ?.getxattr ? ? ? = generic_getxattr,
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index c77b0bd..eafc188 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4191,11 +4191,37 @@ err_out:
> ?int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
> ? ? ? ? ? ? ? ? struct kstat *stat)
> ?{
> - ? ? ? struct inode *inode;
> - ? ? ? unsigned long delalloc_blocks;
> + ? ? ? struct inode *inode = dentry->d_inode;
> + ? ? ? struct ext4_inode_info *ei = EXT4_I(inode);
> +
> + ? ? ? stat->result_mask |= XSTAT_BTIME;
> + ? ? ? stat->btime.tv_sec = ei->i_crtime.tv_sec;
> + ? ? ? stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
> +
> + ? ? ? if (inode->i_ino != EXT4_ROOT_INO) {
> + ? ? ? ? ? ? ? stat->result_mask |= XSTAT_GEN;
> + ? ? ? ? ? ? ? stat->gen = inode->i_generation;
> + ? ? ? }
> + ? ? ? if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) {
> + ? ? ? ? ? ? ? stat->result_mask |= XSTAT_VERSION;
> + ? ? ? ? ? ? ? stat->version = inode->i_version;
> + ? ? ? }
> +
> + ? ? ? ext4_get_inode_flags(ei);
> + ? ? ? stat->ioc_flags |= ei->i_flags & EXT4_FL_USER_VISIBLE;
> + ? ? ? stat->result_mask |= XSTAT_IOC_FLAGS;
>
> - ? ? ? inode = dentry->d_inode;
> ? ? ? ?generic_fillattr(inode, stat);
> + ? ? ? return 0;
> +}
> +
> +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
> + ? ? ? ? ? ? ? ? ? ? struct kstat *stat)
> +{
> + ? ? ? struct inode *inode = dentry->d_inode;
> + ? ? ? u64 delalloc_blocks;
> +
> + ? ? ? ext4_getattr(mnt, dentry, stat);
>
> ? ? ? ?/*
> ? ? ? ? * We can't update i_blocks if the block allocation is delayed
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 349d7b3..6162387 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -2579,6 +2579,7 @@ const struct inode_operations ext4_dir_inode_operations = {
> ? ? ? ?.mknod ? ? ? ? ?= ext4_mknod,
> ? ? ? ?.rename ? ? ? ? = ext4_rename,
> ? ? ? ?.setattr ? ? ? ?= ext4_setattr,
> + ? ? ? .getattr ? ? ? ?= ext4_getattr,
> ?#ifdef CONFIG_EXT4_FS_XATTR
> ? ? ? ?.setxattr ? ? ? = generic_setxattr,
> ? ? ? ?.getxattr ? ? ? = generic_getxattr,
> @@ -2591,6 +2592,7 @@ const struct inode_operations ext4_dir_inode_operations = {
>
> ?const struct inode_operations ext4_special_inode_operations = {
> ? ? ? ?.setattr ? ? ? ?= ext4_setattr,
> + ? ? ? .getattr ? ? ? ?= ext4_getattr,
> ?#ifdef CONFIG_EXT4_FS_XATTR
> ? ? ? ?.setxattr ? ? ? = generic_setxattr,
> ? ? ? ?.getxattr ? ? ? = generic_getxattr,
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index ceebaf8..2d395bf 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3040,6 +3040,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
> ? ? ? ?if (sb->s_magic != EXT4_SUPER_MAGIC)
> ? ? ? ? ? ? ? ?goto cantfind_ext4;
> ? ? ? ?sbi->s_kbytes_written = le64_to_cpu(es->s_kbytes_written);
> + ? ? ? memcpy(sb->s_volume_id, es->s_uuid, sizeof(sb->s_volume_id));
>
> ? ? ? ?/* Set defaults before we parse the mount options */
> ? ? ? ?def_mount_opts = le32_to_cpu(es->s_default_mount_opts);
> diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
> index ed9354a..d8fe7fb 100644
> --- a/fs/ext4/symlink.c
> +++ b/fs/ext4/symlink.c
> @@ -35,6 +35,7 @@ const struct inode_operations ext4_symlink_inode_operations = {
> ? ? ? ?.follow_link ? ?= page_follow_link_light,
> ? ? ? ?.put_link ? ? ? = page_put_link,
> ? ? ? ?.setattr ? ? ? ?= ext4_setattr,
> + ? ? ? .getattr ? ? ? ?= ext4_getattr,
> ?#ifdef CONFIG_EXT4_FS_XATTR
> ? ? ? ?.setxattr ? ? ? = generic_setxattr,
> ? ? ? ?.getxattr ? ? ? = generic_getxattr,
> @@ -47,6 +48,7 @@ const struct inode_operations ext4_fast_symlink_inode_operations = {
> ? ? ? ?.readlink ? ? ? = generic_readlink,
> ? ? ? ?.follow_link ? ?= ext4_follow_link,
> ? ? ? ?.setattr ? ? ? ?= ext4_setattr,
> + ? ? ? .getattr ? ? ? ?= ext4_getattr,
> ?#ifdef CONFIG_EXT4_FS_XATTR
> ? ? ? ?.setxattr ? ? ? = generic_setxattr,
> ? ? ? ?.getxattr ? ? ? = generic_getxattr,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

--
Thanks,

Steve

2012-04-27 00:33:16

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDE1OjA1IC0wNzAwLCBSb2xhbmQgTWNHcmF0aCB3cm90ZToN
Cj4gPiBXaGF0IGlmIHRoZSB4c3RhdCgpIGFuZCBzdHJ1Y3QgeHN0YXQgZXZlbnR1YWxseSBiZWNv
bWVzIHdoYXQgdXNlcnNwYWNlDQo+ID4gdXNlcyBhcyBzdGF0KCkgKGFzIGEgd3JhcHBlcikgYW5k
IHN0cnVjdCBzdGF0IChpZiBzdWNoIGEgdGhpbmcgaXMNCj4gPiBwb3NzaWJsZSB3aXRoIGdsaWJj
IHZlcnNpb25pbmcpPyAgDQo+IA0KPiBJdCdzIGNlcnRhaW5seSBwb3NzaWJsZSB3aXRoIHN5bWJv
bCB2ZXJzaW9uaW5nLCB0aG91Z2ggaXQgc2VlbXMgbXVjaCBtb3JlDQo+IGxpa2VseSB0aGF0IHdl
J2Qgc3RpY2sgd2l0aCB0aGUgZXhpc3Rpbmcgc3RydWN0IHN0YXQgYW5kIHN0YXQqIGludGVyZmFj
ZXMNCj4gYW5kIG9ubHkgaGF2ZSB0aGUgaW1wbGVtZW50YXRpb24gdXNpbmcgc3RhdHggdW5kZXJu
ZWF0aCAoZS5nLiBmb3IgbmV3DQo+IG1hY2hpbmVzIG9yIGtlcm5lbCBBQklzIHdoZXJlIHRoZSBr
ZXJuZWwgc3RvcHMgcHJvdmlkaW5nIGFueSBjYWxscyBleGNlcHQNCj4gZm9yIHN0YXR4YXQpLCBh
dCBsZWFzdCBmb3IgdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZS4NCj4gDQo+ID4gRG8gb2xkZXIgcHJv
Z3JhbXMgdGhhdCB0aGluayB0aGV5J3JlIHVzaW5nIHN0YXQoKSBhbmQgZG9uJ3Qga25vdyBhYm91
dA0KPiA+IHRoZSBleHRyYSBmaWVsZHMgYXZhaWxhYmxlIGV4cGVjdCB0byBzZWUgYSB1c2VmdWwg
dmFsdWUgaW4gc3RfaW5vPw0KPiANCj4gUE9TSVggcmVxdWlyZXMgdGhhdCBzdF9pbm8gaGF2ZSBh
IHVzZWZ1bCB2YWx1ZSBmb3IgdGhlIHN0YW5kYXJkICpzdGF0IGNhbGxzLg0KDQpZZXMsIGJ1dCB3
ZSdyZSB0YWxraW5nIGFib3V0IG5vbi1QT1NJWCBmaWxlc3lzdGVtcyBoZXJlLiBJZiB0aGUNCmZp
bGVzeXN0ZW0gZG9lc24ndCBoYXZlIGEgdXNlZnVsIHZhbHVlIGZvciBzdF9pbm8sIHRoZW4gdGhl
IHVzdWFsIHdheSBvZg0KZGVhbGluZyB3aXRoIHRob3NlIFBPU0lYIHJlcXVpcmVtZW50cyBpcyB0
byBmYWtlIHVwIHZhbHVlcy4gVGhlIHF1ZXN0aW9uDQp0aGVuIGJlY29tZXMgd2hldGhlciBvciBu
b3Qgd2UgY2FyZSBpZiBpdCBpcyB0aGUga2VybmVsIG9yIHVzZXJsYW5kIHRoYXQNCmZha2VzIHVw
IHRob3NlIHZhbHVlcy4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQg
bWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0
YXBwLmNvbQ0KDQo=

2012-04-26 13:46:51

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

Steve French <[email protected]> wrote:

> I also would prefer that we simply treat the time granularity as part
> of the superblock (mounted volume) ie returned on fstat rather than on
> every stat of the filesystem. For cifs mounts we could conceivably
> have different time granularity (1 or 2 second) on mounts to old
> servers rather than 100 nanoseconds.

The question is whether you want to have to do a statfs in addition to a stat?
I suppose you can potentially cache the statfs based on device number.

That said, there are cases where caching filesystem-level info based on i_dev
doesn't work. OpenAFS springs to mind as that only has one superblock and
thus one set of device numbers, but keeps all the inodes for all the different
volumes it may have mounted there.

I don't know whether this would be a problem for CIFS too - say on a windows
server you fabricate P:, for example, by joining together several filesystems
(with junctions?). How does this appear on a Linux client when it steps from
one filesystem to another within a mounted share?

David

2012-04-19 23:25:59

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 2012-04-19, at 8:05 AM, David Howells wrote:
> Implement a pair of new system calls to provide extended and further
> extensible stat functions.

Hallelujah for this. I've been waiting/wanting something like this
for ages already. Now if only we can get this landed before it
degrades into the mess it did last time.

> Should fxstat() be implemented as xstat() with a NULL filename,
> using dfd as fd?

I'm personally inclined toward fewer syscalls, especially since
the fstatxat()->statxat() mapping (if I can be so bold as to
prefer the names used later in this thread) is IMHO clear and
unambiguous, and avoids several thin wrappers in the kernel.

> Should the default for a network fs be to do an unconditional
> (heavyweight) stat with a flag to suppress going to the server
> to update the locally held attributes and flushing pending writebacks?

NOOOooo! If application writers are going to use this, they should
request the information needed, and no more. Make no assumptions
about what information is easy or hard for a filesystem to return,
since the overhead can vary wildly depending on the implementation.

Something like "ls --color" (no -l or -s) always stats the file just
to get the mode bits to color executable files differently. Having
to return other information that isn't totally free almost ruins the
benefit of adding a new syscall in the first place.

> Should things like the Windows Archive, Hidden and System bits be
> handled through IOC flags, perhaps expanded to 64-bits?

I'm definitely in favour of a 64-bit IOC flags value, since they are
getting close to running out already. As to whether those other bits
should be merged into the IOC flags, I'm mostly indifferent, but I
lean toward including them since they are definitely related.

I wouldn't object to 64-bit UID/GID values or split 32-bit low/hi UID
and GID values, since NFSv4 and Kerberos realms will likely need this
at some point as well. That said, if the API is extensible, it would
be just as easy to add the low/hi split values when they are needed
in the future.

> Are these things useful to userspace other than Samba and userspace
> NFS servers?

Definitely yes. The GNU fileutils can use a lot of this, since they
are VERY stat() heavy for things like checking st_dev and st_ino
changes during directory traversal, but don't need any of the other
info.

> Is it useful to pass the volume ID out? Or is statfs() sufficient
> for this?

Can't hurt, IMHO. It is a better (more persistent) identifier than
st_dev, and if it is free, or explicitly requested by the application
(Samba, Ganesha, etc) it can be very useful.

Cheers, Andreas

2012-04-26 17:06:24

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Thu, Apr 26, 2012 at 9:28 AM, J. Bruce Fields <[email protected]> wrote:
> On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
>> Steve French <[email protected]> wrote:
>>
>> > I also would prefer that we simply treat the time granularity as part
>> > of the superblock (mounted volume) ie returned on fstat rather than on
>> > every stat of the filesystem. ? For cifs mounts we could conceivably
>> > have different time granularity (1 or 2 second) on mounts to old
>> > servers rather than 100 nanoseconds.
>>
>> The question is whether you want to have to do a statfs in addition to a stat?
>> I suppose you can potentially cache the statfs based on device number.
>>
>> That said, there are cases where caching filesystem-level info based on i_dev
>> doesn't work. ?OpenAFS springs to mind as that only has one superblock and
>> thus one set of device numbers, but keeps all the inodes for all the different
>> volumes it may have mounted there.
>>
>> I don't know whether this would be a problem for CIFS too - say on a windows
>> server you fabricate P:, for example, by joining together several filesystems
>> (with junctions?). ?How does this appear on a Linux client when it steps from
>> one filesystem to another within a mounted share?
>
> In the NFS case we do try to preserve filesystem boundaries as well as
> we can--the protocol has an fsid field and the client creates a new
> mount each time it sees it change. ?And the protocol defines time_delta
> as a per-filesystem attribute (though, somewhat hilariously, there's
> also a per-filesystem "homogeneous" attribute that a server can clear to
> indicate the per-filesystem attributes might actually vary within the
> filesystem.)

Thank you for reminding me, I need to look at this case more ...
although cifs creates implicit submounts (as we traverse DFS referrals)
there are probably cases where we need to do the same thing as NFS
and look at the fsid so we don't run into a Windows server
exporting something with a "junction" (e.g. directory redirection to
a DVD drive for example) and thus cross file system volume boundaries.

--
Thanks,

Steve

2012-04-27 03:11:28

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On 2012-04-26, at 6:51 PM, Dave Chinner wrote:
> On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
>> I wonder if there's a way to make this explicit - or is it something that if the bit isn't set, you can't use the value in st_blksize.
>> I wonder if this value always has to be non-zero to make sure existing
>> stat() doesn't explode.
>
> More likely it probably needs to be non-zero to prevent applications
> doing division by block size from exploding... ;)

Right, and any application which knows it needs the blocksize should
also be requesting it when using the statxat() (or whatever) syscall.

Cheers, Andreas

2012-04-28 00:54:13

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Fri, Apr 27, 2012 at 7:38 PM, Dave Chinner <[email protected]> wrote:
> preferred minimum IO size (mp->m_readio_log/mp->m_writeio_log)

This discussion about i/o sizes is very interesting. For network
file system (at least for SMB2 to all known servers, and
for cifs mounts to Samba, but probably for recent NFS), ideal i/o
sizes are often well over a megabyte ... but how to indicate that to
the application...

> That's why I'd prefer specific optimal IO hints - we don't have to
> overload st_blksize with lots of meanings to pass what is relatively
> trivial information back to the application.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner

Yes.

--
Thanks,

Steve

2012-04-26 15:52:57

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Steve French <[email protected]> wrote:

> >> Would it be better to make the stable vs volatile inode number an attribute
> >> of the volume or something returned by the proposed xstat?
> >
> > I'm not sure what you mean by a stable vs a volatile inode number.
>
> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent unique
> identifier, but in the case of CIFS some old servers don't support the calls
> which return inode numbers (or don't return them for all file system types,
> Windows FAT?) so in these cases cifs has to create inode numbers on the fly
> on the client. inode numbers created on the client are not "stable" they can
> change on unmount/remount (which can cause problems for backup applications).

In the volatile case you'd probably want to unset XSTAT_INO in st_mask as the
inode number is a local fabrication. However, since there is a remote file ID,
we could add an XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr
holding this. On CIFS this could be the servername + pathname, on NFS this
could be the server address + FH on AFS the cell+volID+FID+uniquifier for
example. That's independent of xstat, however, and wouldn't be returned as
it's a blob that could be quite large.

I presume in some cases, there is not a unique file ID that persists across
rename.

> Similarly NFSv4 does not require that servers always return stable inode
> numbers (that will never change) and introduced a concept of "volatile file
> handle."

Can I presume the inode number cannot be considered stable if the NFS4 FH is
non-volatile? Furthermore, can I presume NFS2/3 inode numbers are supposed to
be stable?

> Basically the question is whether it is worth reporting a flag on the call
> which returns the inode number to indicate that the inode number is "stable"
> (would not change on reboot or reconnection) or "volatile." Since the
> majority of NFS and SMB2 servers can return stable inode numbers, I don't
> feel strongly about the need for an indicator of "stable" vs. "volatile" but
> I mention it because backup and migration applications mention this (if inode
> numbers are volatile, they may have to check for hardlinks differently for
> example)

It may be that unsetting XSTAT_INO if you've fabricated the inode number
locally is sufficient.

> >> > Handle remote filesystems being offline and indicate this with
> >> > XSTAT_INFO_OFFLINE.
> >>
> >> You already have support for an indicator for offline files (HSM),

Which indicator is this? Or do you mean XSTAT_INFO_OFFLINE?

> >> would XSTAT_INFO_OFFLINE be intended for the case
> >> where the network session to the server is disconnected
> >> (and in which you case the application does not want to reconnect)?
> >
> > Hmmm... Interesting question. Both NTFS and CIFS have an offline
> > attribute (which is where I originally got this from) - but should I have a
> > separate indicator to indicate the client can't access a server over a
> > network (ie. we've gone to disconnected operation on this file)?
> > E.g. should there be a XSTAT_INFO_DISCONNECTED too?
>
> my reaction is no, since it adds complexity. If you do a stat on a
> disconnected volume (where the network is temporarily down) reconnection will
> be attempted. If reconnection fails then the xstat will either fail or be
> retried forever depending on the value of "hard" vs. "soft" mount flag.

I was thinking of how to handle disconnected operation, where you can't just
sit there and churn waiting for the server to come back or give an error. On
the other hand, as long as there's some spare space in the struct, we can deal
with that later when we actually start to implement D/O.

David

2012-04-25 14:33:38

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On 2012-04-24, at 4:29 PM, J. Bruce Fields wrote:
> On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
>> (11) Include granularity fields in the time data to indicate the
>> granularity of each of the times (NFSv4 time_delta) [Steve French].
>
> It looks like you're including this with *each* time? But surely
> there's no filesystem with different granularity (say) for ctime than
> for mtime. Also, nfsd will want only one time_delta, not one for each
> time.

I suspect the main reason for having a separate time_delta per timestamp
is to use the extra 32-bit field in the timestamp structs. Since those
structs have a 64-bit + 32-bit field, it would be messy to pack them,
and leaving the spare bytes unused and adding an additional field for
the granularity would just increase the struct size.

> Note also we need to document carefully what this means: I think it
> should be the granularity that the filesystem is capable of
> representing, but people are sometimes surprised to find out that the
> actual time source is usually more coarse-grained than that.
>
> --b.
>
>>
>> (12) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.
>>
>> (13) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
>> Michael Kerrisk].
>>
>> (14) Spare space, request flags and information flags are provided for future
>> expansion.
>>
>>
>> The following structures are defined for the use of these new system calls:
>>
>> struct xstat_dev {
>> uint32_t major, minor;
>> };
>>
>> struct xstat_time {
>> uint64_t tv_sec;
>> uint32_t tv_nsec;
>> uint32_t tv_granularity;
>> };
>>
>> struct xstat {
>> uint32_t st_mask;
>> uint32_t st_mode;
>> uint32_t st_nlink;
>> uint32_t st_uid;
>> uint32_t st_gid;
>> uint32_t st_information;
>> uint32_t st_ioc_flags;
>> uint32_t st_blksize;
>> struct xstat_dev st_rdev;
>> struct xstat_dev st_dev;
>> struct xstat_time st_atime;
>> struct xstat_time st_btime;
>> struct xstat_time st_ctime;
>> struct xstat_time st_mtime;
>> uint64_t st_ino;
>> uint64_t st_size;
>> uint64_t st_blocks;
>> uint64_t st_gen;
>> uint64_t st_version;
>> uint8_t st_volume_id[16];
>> uint64_t __spares[11];
>> };
>>
>> where st_information is local system information about the file, st_btime is
>> the file creation time, st_gen is the inode generation (i_generation),
>> st_data_version is the data version number (i_version), st_ioc_flags is the
>> flags from FS_IOC_GETFLAGS, st_volume_id is where the volume identified is
>> stored, st_result_mask is a bitmask indicating the data provided and __spares[]
>> are where as-yet undefined fields can be placed.
>>
>> The defined bits in request_mask and st_mask are:
>>
>> XSTAT_MODE Want/got st_mode
>> XSTAT_NLINK Want/got st_nlink
>> XSTAT_UID Want/got st_uid
>> XSTAT_GID Want/got st_gid
>> XSTAT_RDEV Want/got st_rdev
>> XSTAT_ATIME Want/got st_atime
>> XSTAT_MTIME Want/got st_mtime
>> XSTAT_CTIME Want/got st_ctime
>> XSTAT_INO Want/got st_ino
>> XSTAT_SIZE Want/got st_size
>> XSTAT_BLOCKS Want/got st_blocks
>> XSTAT_BASIC_STATS [The stuff in the normal stat struct]
>> XSTAT_IOC_FLAGS Want/got FS_IOC_GETFLAGS
>> XSTAT_BTIME Want/got st_btime
>> XSTAT_GEN Want/got st_gen
>> XSTAT_VERSION Want/got st_data_version
>> XSTAT_VOLUME_ID Want/got st_volume_id
>> XSTAT_ALL_STATS [All currently available stuff]
>>
>> The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra flags
>> that might be supplied by the filesystem. Note that Ext4 returns flags outside
>> of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS. Should
>> {EXT4,FS}_FL_USER_VISIBLE be extended to cover them? Or should the extra flags
>> be suppressed?
>>
>> The defined bits in the st_information field give local system data on a file,
>> how it is accessed, where it is and what it does:
>>
>> XSTAT_INFO_ENCRYPTED File is encrypted
>> XSTAT_INFO_TEMPORARY File is temporary (NTFS/CIFS/deleted)
>> XSTAT_INFO_FABRICATED File was made up by filesystem
>> XSTAT_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs)
>> XSTAT_INFO_REMOTE File is remote
>> XSTAT_INFO_OFFLINE File is offline (CIFS)
>> XSTAT_INFO_AUTOMOUNT Dir is automount trigger
>> XSTAT_INFO_AUTODIR Dir provides unlisted automounts
>> XSTAT_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details
>> XSTAT_INFO_HAS_ACL File has an ACL of some sort
>> XSTAT_INFO_REPARSE_POINT File is reparse point (NTFS/CIFS)
>> XSTAT_INFO_HIDDEN File is marked hidden (DOS+)
>> XSTAT_INFO_SYSTEM File is marked system (DOS+)
>> XSTAT_INFO_ARCHIVE File is marked archive (DOS+)
>>
>> These are for the use of GUI tools that might want to mark files specially,
>> depending on what they are. I've tried not to provide overlap with
>> st_ioc_flags where something usable exists there. Should Hidden, System and
>> Archive flags be associated with ioc_flags, perhaps with ioc_flags extended to
>> 64-bits?
>>
>>
>> The system calls are:
>>
>> ssize_t ret = xstat(int dfd,
>> const char *filename,
>> unsigned int flags,
>> unsigned int mask,
>> struct xstat *buffer);
>>
>> ssize_t ret = fxstat(unsigned fd,
>> unsigned int flags,
>> unsigned int mask,
>> struct xstat *buffer);
>>
>>
>> The dfd, filename, flags and fd parameters indicate the file to query. There
>> is no equivalent of lstat() as that can be emulated with xstat() by passing
>> AT_SYMLINK_NOFOLLOW in flags.
>>
>> AT_FORCE_ATTR_SYNC can also be set in flags. This will require a network
>> filesystem to synchronise its attributes with the server.
>>
>> mask is a bitmask indicating the fields in struct xstat that are of interest to
>> the caller. The user should set this to XSTAT__BASIC_STATS to get the
>> basic set returned by stat().
>>
>> Should there just be one xstat() syscall that does fxstat() if filename is NULL?
>>
>> The fields in struct xstat come in a number of classes:
>>
>> (0) st_dev, st_blksize, st_information.
>>
>> These are local data and are always available.
>>
>> (1) st_mode, st_nlinks, st_uid, st_gid, st_[amc]time, st_ino, st_size,
>> st_blocks.
>>
>> These will be returned whether the caller asks for them or not. The
>> corresponding bits in result_mask will be set to indicate their presence.
>>
>> If the caller didn't ask for them, then they may be approximated. For
>> example, NFS won't waste any time updating them from the server, unless as
>> a byproduct of updating something requested.
>>
>> If the values don't actually exist for the underlying object (such as UID
>> or GID on a DOS file), then the bit won't be set in the result_mask, even
>> if the caller asked for the value and the returned value will be a
>> fabrication.
>>
>> (2) st_rdev.
>>
>> As for class (1), but this won't be returned if the file is not a blockdev
>> or chardev. The bit will be cleared if the value is not returned.
>>
>> (3) File creation time (st_btime), inode generation (st_gen), data version
>> (st_version), volume_id (st_volume_id) and inode flags (st_ioc_flags).
>>
>> These will be returned if available whether the caller asked for them or
>> not. The corresponding bits in result_mask will be set or cleared as
>> appropriate to indicate their presence.
>>
>> If the caller didn't ask for them, then they may be approximated. For
>> example, NFS won't waste any time updating them from the server, unless
>> as a byproduct of updating something requested.
>>
>> At the moment, this will only work on x86_64 and i386 as it requires system
>> calls to be wired up.
>>
>>
>> =======
>> TESTING
>> =======
>>
>> The following test program can be used to test the xstat system call:
>>
>> /* Test the xstat() system call
>> *
>> * Copyright (C) 2010 Red Hat, Inc. All Rights Reserved.
>> * Written by David Howells ([email protected])
>> *
>> * This program is free software; you can redistribute it and/or
>> * modify it under the terms of the GNU General Public Licence
>> * as published by the Free Software Foundation; either version
>> * 2 of the Licence, or (at your option) any later version.
>> */
>>
>> #define _GNU_SOURCE
>> #define _ATFILE_SOURCE
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <string.h>
>> #include <unistd.h>
>> #include <fcntl.h>
>> #include <time.h>
>> #include <sys/syscall.h>
>> #include <sys/stat.h>
>> #include <sys/types.h>
>>
>> #define AT_NO_AUTOMOUNT 0x800
>> #define AT_FORCE_ATTR_SYNC 0x2000
>>
>> #define XSTAT_MODE 0x00000001U
>> #define XSTAT_NLINK 0x00000002U
>> #define XSTAT_UID 0x00000004U
>> #define XSTAT_GID 0x00000008U
>> #define XSTAT_RDEV 0x00000010U
>> #define XSTAT_ATIME 0x00000020U
>> #define XSTAT_MTIME 0x00000040U
>> #define XSTAT_CTIME 0x00000080U
>> #define XSTAT_INO 0x00000100U
>> #define XSTAT_SIZE 0x00000200U
>> #define XSTAT_BLOCKS 0x00000400U
>> #define XSTAT_BASIC_STATS 0x000007ffU
>> #define XSTAT_BTIME 0x00000800U
>> #define XSTAT_GEN 0x00001000U
>> #define XSTAT_VERSION 0x00002000U
>> #define XSTAT_IOC_FLAGS 0x00004000U
>> #define XSTAT_VOLUME_ID 0x00008000U
>> #define XSTAT_ALL_STATS 0x0000ffffU
>>
>> struct xstat_dev {
>> uint32_t major;
>> uint32_t minor;
>> };
>>
>> struct xstat_time {
>> uint64_t tv_sec;
>> uint32_t tv_nsec;
>> uint32_t tv_granularity;
>> };
>>
>> struct xstat {
>> uint32_t st_mask;
>> uint32_t st_mode;
>> uint32_t st_nlink;
>> uint32_t st_uid;
>> uint32_t st_gid;
>> uint32_t st_information;
>> uint32_t st_ioc_flags;
>> uint32_t st_blksize;
>> struct xstat_dev st_rdev;
>> struct xstat_dev st_dev;
>> struct xstat_time st_atim;
>> struct xstat_time st_btim;
>> struct xstat_time st_ctim;
>> struct xstat_time st_mtim;
>> uint64_t st_ino;
>> uint64_t st_size;
>> uint64_t st_blksize;
>> uint64_t st_blocks;
>> uint64_t st_gen;
>> uint64_t st_version;
>> uint64_t st_volume_id[16];
>> uint64_t st_spares[11];
>> };
>>
>> #define XSTAT_INFO_ENCRYPTED 0x00000001U
>> #define XSTAT_INFO_TEMPORARY 0x00000002U
>> #define XSTAT_INFO_FABRICATED 0x00000004U
>> #define XSTAT_INFO_KERNEL_API 0x00000008U
>> #define XSTAT_INFO_REMOTE 0x00000010U
>> #define XSTAT_INFO_OFFLINE 0x00000020U
>> #define XSTAT_INFO_AUTOMOUNT 0x00000040U
>> #define XSTAT_INFO_AUTODIR 0x00000080U
>> #define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U
>> #define XSTAT_INFO_HAS_ACL 0x00000200U
>> #define XSTAT_INFO_REPARSE_POINT 0x00000400U
>> #define XSTAT_INFO_HIDDEN 0x00000800U
>> #define XSTAT_INFO_SYSTEM 0x00001000U
>> #define XSTAT_INFO_ARCHIVE 0x00002000U
>>
>> #define __NR_xstat 312
>> #define __NR_fxstat 313
>>
>> static __attribute__((unused))
>> ssize_t xstat(int dfd, const char *filename, unsigned flags,
>> unsigned int mask, struct xstat *buffer)
>> {
>> return syscall(__NR_xstat, dfd, filename, flags, mask, buffer);
>> }
>>
>> static __attribute__((unused))
>> ssize_t fxstat(int fd, unsigned flags,
>> unsigned int mask, struct xstat *buffer)
>> {
>> return syscall(__NR_fxstat, fd, flags, mask, buffer);
>> }
>>
>> static void print_time(const char *field, const struct xstat_time *xstm)
>> {
>> struct tm tm;
>> time_t tim;
>> char buffer[100];
>> int len;
>>
>> tim = xstm->tv_sec;
>> if (!localtime_r(&tim, &tm)) {
>> perror("localtime_r");
>> exit(1);
>> }
>> len = strftime(buffer, 100, "%F %T", &tm);
>> if (len == 0) {
>> perror("strftime");
>> exit(1);
>> }
>> printf("%s", field);
>> fwrite(buffer, 1, len, stdout);
>> printf(".%09u", xstm->tv_nsec);
>> len = strftime(buffer, 100, "%z", &tm);
>> if (len == 0) {
>> perror("strftime2");
>> exit(1);
>> }
>> fwrite(buffer, 1, len, stdout);
>> printf("\n");
>> }
>>
>> static void dump_xstat(struct xstat *xst)
>> {
>> char buffer[256], ft;
>>
>> printf("results=%x\n", xst->st_mask);
>>
>> printf(" ");
>> if (xst->st_mask & XSTAT_SIZE)
>> printf(" Size: %-15llu", (unsigned long long) xst->st_size);
>> if (xst->st_mask & XSTAT_BLOCKS)
>> printf(" Blocks: %-10llu", (unsigned long long) xst->st_blocks);
>> printf(" IO Block: %-6llu ", (unsigned long long) xst->st_blksize);
>> if (xst->st_mask & XSTAT_MODE) {
>> switch (xst->st_mode & S_IFMT) {
>> case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break;
>> case S_IFCHR: printf(" character special file\n"); ft = 'c'; break;
>> case S_IFDIR: printf(" directory\n"); ft = 'd'; break;
>> case S_IFBLK: printf(" block special file\n"); ft = 'b'; break;
>> case S_IFREG: printf(" regular file\n"); ft = '-'; break;
>> case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break;
>> case S_IFSOCK: printf(" socket\n"); ft = 's'; break;
>> default:
>> printf("unknown type (%o)\n", xst->st_mode & S_IFMT);
>> ft = '?';
>> break;
>> }
>> }
>>
>> sprintf(buffer, "%02x:%02x", xst->st_dev.major, xst->st_dev.minor);
>> printf("Device: %-15s", buffer);
>> if (xst->st_mask & XSTAT_INO)
>> printf(" Inode: %-11llu", (unsigned long long) xst->st_ino);
>> if (xst->st_mask & XSTAT_SIZE)
>> printf(" Links: %-5u", xst->st_nlink);
>> if (xst->st_mask & XSTAT_RDEV)
>> printf(" Device type: %u,%u",
>> xst->st_rdev.major, xst->st_rdev.minor);
>> printf("\n");
>>
>> if (xst->st_mask & XSTAT_MODE)
>> printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ",
>> xst->st_mode & 07777,
>> ft,
>> xst->st_mode & S_IRUSR ? 'r' : '-',
>> xst->st_mode & S_IWUSR ? 'w' : '-',
>> xst->st_mode & S_IXUSR ? 'x' : '-',
>> xst->st_mode & S_IRGRP ? 'r' : '-',
>> xst->st_mode & S_IWGRP ? 'w' : '-',
>> xst->st_mode & S_IXGRP ? 'x' : '-',
>> xst->st_mode & S_IROTH ? 'r' : '-',
>> xst->st_mode & S_IWOTH ? 'w' : '-',
>> xst->st_mode & S_IXOTH ? 'x' : '-');
>> if (xst->st_mask & XSTAT_UID)
>> printf("Uid: %d \n", xst->st_uid);
>> if (xst->st_mask & XSTAT_GID)
>> printf("Gid: %u\n", xst->st_gid);
>>
>> if (xst->st_mask & XSTAT_ATIME)
>> print_time("Access: ", &xst->st_atim);
>> if (xst->st_mask & XSTAT_MTIME)
>> print_time("Modify: ", &xst->st_mtim);
>> if (xst->st_mask & XSTAT_CTIME)
>> print_time("Change: ", &xst->st_ctim);
>> if (xst->st_mask & XSTAT_BTIME)
>> print_time("Create: ", &xst->st_btim);
>>
>> if (xst->st_mask & XSTAT_GEN)
>> printf("Inode version: %llxh\n", (unsigned long long) xst->st_gen);
>> if (xst->st_mask & XSTAT_VERSION)
>> printf("Data version: %llxh\n", (unsigned long long) xst->st_version);
>>
>> if (xst->st_mask & XSTAT_IOC_FLAGS) {
>> unsigned char bits;
>> int loop, byte;
>>
>> static char flag_representation[32 + 1] =
>> /* FS_IOC_GETFLAGS flags: */
>> "????????" /* 31-24 0x00000000-ff000000 */
>> "????ehTD" /* 23-16 0x00000000-00ff0000 */
>> "tj?IE?XZ" /* 15- 8 0x00000000-0000ff00 */
>> "AdaiScus" /* 7- 0 0x00000000-000000ff */
>> ;
>>
>> printf("Inode flags: %08x (", xst->st_ioc_flags);
>> for (byte = 32 - 8; byte >= 0; byte -= 8) {
>> bits = xst->st_ioc_flags >> byte;
>> for (loop = 7; loop >= 0; loop--) {
>> int bit = byte + loop;
>>
>> if (bits & 0x80)
>> putchar(flag_representation[31 - bit]);
>> else
>> putchar('-');
>> bits <<= 1;
>> }
>> if (byte)
>> putchar(' ');
>> }
>> printf(")\n");
>> }
>>
>> if (xst->st_information) {
>> unsigned char bits;
>> int loop, byte;
>>
>> static char info_representation[32 + 1] =
>> /* XSTAT_INFO_ flags: */
>> "????????" /* 31-24 0x00000000-ff000000 */
>> "????????" /* 23-16 0x00000000-00ff0000 */
>> "??ASHRan" /* 15- 8 0x00000000-0000ff00 */
>> "dmorkfte" /* 7- 0 0x00000000-000000ff */
>> ;
>>
>> printf("Information: %08x (", xst->st_information);
>> for (byte = 32 - 8; byte >= 0; byte -= 8) {
>> bits = xst->st_information >> byte;
>> for (loop = 7; loop >= 0; loop--) {
>> int bit = byte + loop;
>>
>> if (bits & 0x80)
>> putchar(info_representation[31 - bit]);
>> else
>> putchar('-');
>> bits <<= 1;
>> }
>> if (byte)
>> putchar(' ');
>> }
>> printf(")\n");
>> }
>>
>> if (xst->st_mask & XSTAT_VOLUME_ID) {
>> int loop;
>> printf("Volume ID: ");
>> for (loop = 0; loop < sizeof(xst->st_volume_id); loop++) {
>> printf("%02x", xst->st_volume_id[loop]);
>> if (loop == 7)
>> printf("-");
>> }
>> printf("\n");
>> }
>> }
>>
>> void dump_hex(unsigned long long *data, int from, int to)
>> {
>> unsigned offset, print_offset = 1, col = 0;
>>
>> from /= 8;
>> to = (to + 7) / 8;
>>
>> for (offset = from; offset < to; offset++) {
>> if (print_offset) {
>> printf("%04x: ", offset * 8);
>> print_offset = 0;
>> }
>> printf("%016llx", data[offset]);
>> col++;
>> if ((col & 3) == 0) {
>> printf("\n");
>> print_offset = 1;
>> } else {
>> printf(" ");
>> }
>> }
>>
>> if (!print_offset)
>> printf("\n");
>> }
>>
>> int main(int argc, char **argv)
>> {
>> struct xstat xst;
>> int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW;
>>
>> unsigned int mask = XSTAT_ALL_STATS;
>>
>> for (argv++; *argv; argv++) {
>> if (strcmp(*argv, "-F") == 0) {
>> atflag |= AT_FORCE_ATTR_SYNC;
>> continue;
>> }
>> if (strcmp(*argv, "-L") == 0) {
>> atflag &= ~AT_SYMLINK_NOFOLLOW;
>> continue;
>> }
>> if (strcmp(*argv, "-O") == 0) {
>> mask &= ~XSTAT_BASIC_STATS;
>> continue;
>> }
>> if (strcmp(*argv, "-A") == 0) {
>> atflag |= AT_NO_AUTOMOUNT;
>> continue;
>> }
>> if (strcmp(*argv, "-R") == 0) {
>> raw = 1;
>> continue;
>> }
>>
>> memset(&xst, 0xbf, sizeof(xst));
>> ret = xstat(AT_FDCWD, *argv, atflag, mask, &xst);
>> printf("xstat(%s) = %d\n", *argv, ret);
>> if (ret < 0) {
>> perror(*argv);
>> exit(1);
>> }
>>
>> if (raw)
>> dump_hex((unsigned long long *)&xst, 0, sizeof(xst));
>>
>> dump_xstat(&xst);
>> }
>> return 0;
>> }
>>
>> Just compile and run, passing it paths to the files you want to examine:
>>
>> [root@andromeda ~]# /tmp/xstat /proc/$$
>> xstat(/proc/2074) = 160
>> results=47ef
>> Size: 0 Blocks: 0 IO Block: 1024 directory
>> Device: 00:03 Inode: 9072 Links: 7
>> Access: (0555/dr-xr-xr-x) Uid: 0
>> Gid: 0
>> Access: 2010-07-14 16:50:46.609336272+0100
>> Modify: 2010-07-14 16:50:46.609336272+0100
>> Change: 2010-07-14 16:50:46.609336272+0100
>> Inode flags: 0000000100000000 (-------- -------- -------- -------S -------- -------- -------- --------)
>> [root@andromeda ~]# /tmp/xstat /afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm
>> xstat(/afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm) = 160
>> results=77ef
>> Size: 5413882 Blocks: 0 IO Block: 4096 regular file
>> Device: 00:15 Inode: 2288 Links: 1
>> Access: (0644/-rw-r--r--) Uid: 75338
>> Gid: 0
>> Access: 2008-11-05 19:47:22.000000000+0000
>> Modify: 2008-11-05 19:47:22.000000000+0000
>> Change: 2008-11-05 19:47:22.000000000+0000
>> Inode version: 795h
>> Data version: 2h
>> Inode flags: 0000000800000000 (-------- -------- -------- ----r--- -------- -------- -------- --------)
>>
>> Signed-off-by: David Howells <[email protected]>
>> ---
>>
>> arch/x86/syscalls/syscall_32.tbl | 2
>> arch/x86/syscalls/syscall_64.tbl | 2
>> fs/stat.c | 350 +++++++++++++++++++++++++++++++++++---
>> include/linux/fcntl.h | 1
>> include/linux/fs.h | 4
>> include/linux/stat.h | 126 +++++++++++++-
>> include/linux/syscalls.h | 7 +
>> 7 files changed, 461 insertions(+), 31 deletions(-)
>>
>> diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
>> index 29f9f05..980eb5a 100644
>> --- a/arch/x86/syscalls/syscall_32.tbl
>> +++ b/arch/x86/syscalls/syscall_32.tbl
>> @@ -355,3 +355,5 @@
>> 346 i386 setns sys_setns
>> 347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv
>> 348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev
>> +349 i386 xstat sys_xstat
>> +350 i386 fxstat sys_fxstat
>> diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
>> index dd29a9e..7ae24bb 100644
>> --- a/arch/x86/syscalls/syscall_64.tbl
>> +++ b/arch/x86/syscalls/syscall_64.tbl
>> @@ -318,6 +318,8 @@
>> 309 common getcpu sys_getcpu
>> 310 64 process_vm_readv sys_process_vm_readv
>> 311 64 process_vm_writev sys_process_vm_writev
>> +312 common xstat sys_xstat
>> +313 common fxstat sys_fxstat
>> #
>> # x32-specific system call numbers start at 512 to avoid cache impact
>> # for native 64-bit operation.
>> diff --git a/fs/stat.c b/fs/stat.c
>> index c733dc5..af3ef33 100644
>> --- a/fs/stat.c
>> +++ b/fs/stat.c
>> @@ -18,8 +18,20 @@
>> #include <asm/uaccess.h>
>> #include <asm/unistd.h>
>>
>> +/**
>> + * generic_fillattr - Fill in the basic attributes from the inode struct
>> + * @inode: Inode to use as the source
>> + * @stat: Where to fill in the attributes
>> + *
>> + * Fill in the basic attributes in the kstat structure from data that's to be
>> + * found on the VFS inode structure. This is the default if no getattr inode
>> + * operation is supplied.
>> + */
>> void generic_fillattr(struct inode *inode, struct kstat *stat)
>> {
>> + struct super_block *sb = inode->i_sb;
>> + u32 x;
>> +
>> stat->dev = inode->i_sb->s_dev;
>> stat->ino = inode->i_ino;
>> stat->mode = inode->i_mode;
>> @@ -27,17 +39,61 @@ void generic_fillattr(struct inode *inode, struct kstat *stat)
>> stat->uid = inode->i_uid;
>> stat->gid = inode->i_gid;
>> stat->rdev = inode->i_rdev;
>> - stat->size = i_size_read(inode);
>> - stat->atime = inode->i_atime;
>> stat->mtime = inode->i_mtime;
>> stat->ctime = inode->i_ctime;
>> - stat->blksize = (1 << inode->i_blkbits);
>> + stat->size = i_size_read(inode);
>> stat->blocks = inode->i_blocks;
>> -}
>> + stat->blksize = (1 << inode->i_blkbits);
>>
>> + stat->result_mask |= XSTAT_BASIC_STATS & ~XSTAT_RDEV;
>> + if (IS_NOATIME(inode))
>> + stat->result_mask &= ~XSTAT_ATIME;
>> + else
>> + stat->atime = inode->i_atime;
>> +
>> + if (S_ISREG(stat->mode) && stat->nlink == 0)
>> + stat->information |= XSTAT_INFO_TEMPORARY;
>> + if (IS_AUTOMOUNT(inode))
>> + stat->information |= XSTAT_INFO_AUTOMOUNT;
>> + if (IS_POSIXACL(inode))
>> + stat->information |= XSTAT_INFO_HAS_ACL;
>> +
>> + /* if unset, assume 1s granularity */
>> + stat->tv_granularity = sb->s_time_gran ?: 1000000000U;
>> +
>> + if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode)))
>> + stat->result_mask |= XSTAT_RDEV;
>> +
>> + x = ((u32*)&stat->volume_id)[0] = ((u32*)&sb->s_volume_id)[0];
>> + x |= ((u32*)&stat->volume_id)[1] = ((u32*)&sb->s_volume_id)[1];
>> + x |= ((u32*)&stat->volume_id)[2] = ((u32*)&sb->s_volume_id)[2];
>> + x |= ((u32*)&stat->volume_id)[3] = ((u32*)&sb->s_volume_id)[3];
>> + if (x)
>> + stat->result_mask |= XSTAT_VOLUME_ID;
>> +}
>> EXPORT_SYMBOL(generic_fillattr);
>>
>> -int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
>> +/**
>> + * vfs_xgetattr - Get the basic and extra attributes of a file
>> + * @mnt: The mountpoint to which the dentry belongs
>> + * @dentry: The file of interest
>> + * @stat: Where to return the statistics
>> + *
>> + * Ask the filesystem for a file's attributes. The caller must have preset
>> + * stat->request_mask and stat->query_flags to indicate what they want.
>> + *
>> + * If the file is remote, the filesystem can be forced to update the attributes
>> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags.
>> + *
>> + * Bits must have been set in stat->request_mask to indicate which attributes
>> + * the caller wants retrieving. Any such attribute not requested may be
>> + * returned anyway, but the value may be approximate, and, if remote, may not
>> + * have been synchronised with the server.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry,
>> + struct kstat *stat)
>> {
>> struct inode *inode = dentry->d_inode;
>> int retval;
>> @@ -46,64 +102,184 @@ int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
>> if (retval)
>> return retval;
>>
>> + stat->result_mask = 0;
>> + stat->information = 0;
>> + stat->ioc_flags = 0;
>> if (inode->i_op->getattr)
>> return inode->i_op->getattr(mnt, dentry, stat);
>>
>> generic_fillattr(inode, stat);
>> return 0;
>> }
>> +EXPORT_SYMBOL(vfs_xgetattr);
>>
>> +/**
>> + * vfs_getattr - Get the basic attributes of a file
>> + * @mnt: The mountpoint to which the dentry belongs
>> + * @dentry: The file of interest
>> + * @stat: Where to return the statistics
>> + *
>> + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't
>> + * forced to update its files from the backing store. Only the basic set of
>> + * attributes will be retrieved; anyone wanting more must use vfs_getxattr(),
>> + * as must anyone who wants to force attributes to be sync'd with the server.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
>> +{
>> + stat->query_flags = 0;
>> + stat->request_mask = XSTAT_BASIC_STATS;
>> + return vfs_xgetattr(mnt, dentry, stat);
>> +}
>> EXPORT_SYMBOL(vfs_getattr);
>>
>> -int vfs_fstat(unsigned int fd, struct kstat *stat)
>> +/**
>> + * vfs_fxstat - Get basic and extra attributes by file descriptor
>> + * @fd: The file descriptor refering to the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xgetattr(). The main difference is
>> + * that it uses a file descriptor to determine the file location.
>> + *
>> + * The caller must have preset stat->query_flags and stat->request_mask as for
>> + * vfs_xgetattr().
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_fxstat(unsigned int fd, struct kstat *stat)
>> {
>> struct file *f = fget(fd);
>> int error = -EBADF;
>>
>> + if (stat->query_flags & ~KSTAT_QUERY_FLAGS)
>> + return -EINVAL;
>> if (f) {
>> - error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat);
>> + error = vfs_xgetattr(f->f_path.mnt, f->f_path.dentry, stat);
>> fput(f);
>> }
>> return error;
>> }
>> +EXPORT_SYMBOL(vfs_fxstat);
>> +
>> +/**
>> + * vfs_fstat - Get basic attributes by file descriptor
>> + * @fd: The file descriptor refering to the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_getattr(). The main difference is
>> + * that it uses a file descriptor to determine the file location.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_fstat(unsigned int fd, struct kstat *stat)
>> +{
>> + stat->query_flags = 0;
>> + stat->request_mask = XSTAT_BASIC_STATS;
>> + return vfs_fxstat(fd, stat);
>> +}
>> EXPORT_SYMBOL(vfs_fstat);
>>
>> -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>> - int flag)
>> +/**
>> + * vfs_xstat - Get basic and extra attributes by filename
>> + * @dfd: A file descriptor representing the base dir for a relative filename
>> + * @filename: The name of the file of interest
>> + * @flags: Flags to control the query
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xgetattr(). The main difference is
>> + * that it uses a filename and base directory to determine the file location.
>> + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a
>> + * symlink at the given name from being referenced.
>> + *
>> + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The
>> + * flags are also used to load up stat->query_flags.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_xstat(int dfd, const char __user *filename, int flags,
>> + struct kstat *stat)
>> {
>> struct path path;
>> - int error = -EINVAL;
>> - int lookup_flags = 0;
>> + int error, lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
>>
>> - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
>> - AT_EMPTY_PATH)) != 0)
>> - goto out;
>> + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
>> + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
>> + return -EINVAL;
>>
>> - if (!(flag & AT_SYMLINK_NOFOLLOW))
>> - lookup_flags |= LOOKUP_FOLLOW;
>> - if (flag & AT_EMPTY_PATH)
>> + if (flags & AT_SYMLINK_NOFOLLOW)
>> + lookup_flags &= ~LOOKUP_FOLLOW;
>> + if (flags & AT_NO_AUTOMOUNT)
>> + lookup_flags &= ~LOOKUP_AUTOMOUNT;
>> + if (flags & AT_EMPTY_PATH)
>> lookup_flags |= LOOKUP_EMPTY;
>>
>> + stat->query_flags = flags & KSTAT_QUERY_FLAGS;
>> error = user_path_at(dfd, filename, lookup_flags, &path);
>> - if (error)
>> - goto out;
>> -
>> - error = vfs_getattr(path.mnt, path.dentry, stat);
>> - path_put(&path);
>> -out:
>> + if (!error) {
>> + error = vfs_xgetattr(path.mnt, path.dentry, stat);
>> + path_put(&path);
>> + }
>> return error;
>> }
>> +EXPORT_SYMBOL(vfs_xstat);
>> +
>> +/**
>> + * vfs_fstatat - Get basic attributes by filename
>> + * @dfd: A file descriptor representing the base dir for a relative filename
>> + * @filename: The name of the file of interest
>> + * @flags: Flags to control the query
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xstat(). The difference is that it
>> + * preselects basic stats only. The flags are used to load up
>> + * stat->query_flags in addition to indicating symlink handling during path
>> + * resolution.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>> + int flags)
>> +{
>> + stat->request_mask = XSTAT_BASIC_STATS;
>> + return vfs_xstat(dfd, filename, flags, stat);
>> +}
>> EXPORT_SYMBOL(vfs_fstatat);
>>
>> -int vfs_stat(const char __user *name, struct kstat *stat)
>> +/**
>> + * vfs_stat - Get basic attributes by filename
>> + * @filename: The name of the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xstat(). The difference is that it
>> + * preselects basic stats only, terminal symlinks are followed regardless and a
>> + * remote filesystem can't be forced to query the server. If such is desired,
>> + * vfs_xstat() should be used instead.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_stat(const char __user *filename, struct kstat *stat)
>> {
>> - return vfs_fstatat(AT_FDCWD, name, stat, 0);
>> + stat->request_mask = XSTAT_BASIC_STATS;
>> + return vfs_xstat(AT_FDCWD, filename, 0, stat);
>> }
>> EXPORT_SYMBOL(vfs_stat);
>>
>> +/**
>> + * vfs_stat - Get basic attributes by filename, without following terminal symlink
>> + * @filename: The name of the file of interest
>> + * @stat: The result structure to fill in.
>> + *
>> + * This function is a wrapper around vfs_xstat(). The difference is that it
>> + * preselects basic stats only, terminal symlinks are note followed regardless
>> + * and a remote filesystem can't be forced to query the server. If such is
>> + * desired, vfs_xstat() should be used instead.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> int vfs_lstat(const char __user *name, struct kstat *stat)
>> {
>> - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW);
>> + return vfs_xstat(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat);
>> }
>> EXPORT_SYMBOL(vfs_lstat);
>>
>> @@ -118,7 +294,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
>> {
>> static int warncount = 5;
>> struct __old_kernel_stat tmp;
>> -
>> +
>> if (warncount > 0) {
>> warncount--;
>> printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n",
>> @@ -143,7 +319,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
>> #if BITS_PER_LONG == 32
>> if (stat->size > MAX_NON_LFS)
>> return -EOVERFLOW;
>> -#endif
>> +#endif
>> tmp.st_size = stat->size;
>> tmp.st_atime = stat->atime.tv_sec;
>> tmp.st_mtime = stat->mtime.tv_sec;
>> @@ -225,7 +401,7 @@ static int cp_new_stat(struct kstat *stat, struct stat __user *statbuf)
>> #if BITS_PER_LONG == 32
>> if (stat->size > MAX_NON_LFS)
>> return -EOVERFLOW;
>> -#endif
>> +#endif
>> tmp.st_size = stat->size;
>> tmp.st_atime = stat->atime.tv_sec;
>> tmp.st_mtime = stat->mtime.tv_sec;
>> @@ -412,6 +588,122 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
>> }
>> #endif /* __ARCH_WANT_STAT64 */
>>
>> +/*
>> + * Get the xstat parameters if supplied
>> + */
>> +static int xstat_get_params(unsigned int mask, struct xstat __user *buffer,
>> + struct kstat *stat)
>> +{
>> + memset(stat, 0xde, sizeof(*stat)); // DEBUGGING
>> +
>> + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer)))
>> + return -EFAULT;
>> +
>> + stat->request_mask = mask & XSTAT_ALL_STATS;
>> + stat->result_mask = 0;
>> + return 0;
>> +}
>> +
>> +/*
>> + * Set the xstat results.
>> + *
>> + * If the buffer size was 0, we just return the size of the buffer needed to
>> + * return the full result.
>> + *
>> + * If bufsize indicates a buffer of insufficient size to hold the full result,
>> + * we return -E2BIG.
>> + *
>> + * Otherwise we copy the extended stats to userspace and return the amount of
>> + * data written into the buffer (or -EFAULT).
>> + */
>> +static long xstat_set_result(struct kstat *stat, struct xstat __user *buffer)
>> +{
>> + u32 mask = stat->result_mask, gran = stat->tv_granularity;
>> +
>> +#define __put_timestamp(kts, uts) ( \
>> + __put_user(kts.tv_sec, uts.tv_sec ) || \
>> + __put_user(kts.tv_nsec, uts.tv_nsec ) || \
>> + __put_user(gran, uts.tv_granularity ))
>> +
>> + /* clear out anything we're not returning */
>> + if (!(mask & XSTAT_IOC_FLAGS))
>> + stat->ioc_flags = 0;
>> + if (!(mask & XSTAT_BTIME))
>> + memset(&stat->btime, 0, sizeof(stat->btime));
>> + if (!(mask & XSTAT_GEN))
>> + stat->gen = 0;
>> + if (!(mask & XSTAT_VERSION))
>> + stat->version = 0;
>> + if (!(mask & XSTAT_VOLUME_ID))
>> + memset(&stat->volume_id, 0, sizeof(stat->volume_id));
>> +
>> + /* transfer the results */
>> + if (__put_user(mask, &buffer->st_mask ) ||
>> + __put_user(stat->mode, &buffer->st_mode ) ||
>> + __put_user(stat->nlink, &buffer->st_nlink ) ||
>> + __put_user(stat->uid, &buffer->st_uid ) ||
>> + __put_user(stat->gid, &buffer->st_gid ) ||
>> + __put_user(stat->information, &buffer->st_information ) ||
>> + __put_user(stat->ioc_flags, &buffer->st_ioc_flags ) ||
>> + __put_user(stat->blksize, &buffer->st_blksize ) ||
>> + __put_user(MAJOR(stat->rdev), &buffer->st_rdev.major ) ||
>> + __put_user(MINOR(stat->rdev), &buffer->st_rdev.minor ) ||
>> + __put_user(MAJOR(stat->dev), &buffer->st_dev.major ) ||
>> + __put_user(MINOR(stat->dev), &buffer->st_dev.minor ) ||
>> + __put_timestamp(stat->atime, &buffer->st_atime ) ||
>> + __put_timestamp(stat->btime, &buffer->st_btime ) ||
>> + __put_timestamp(stat->ctime, &buffer->st_ctime ) ||
>> + __put_timestamp(stat->mtime, &buffer->st_mtime ) ||
>> + __put_user(stat->ino, &buffer->st_ino ) ||
>> + __put_user(stat->size, &buffer->st_size ) ||
>> + __put_user(stat->blocks, &buffer->st_blocks ) ||
>> + __put_user(stat->gen, &buffer->st_gen ) ||
>> + __put_user(stat->version, &buffer->st_version ) ||
>> + __copy_to_user(&buffer->st_volume_id, &stat->volume_id,
>> + sizeof(buffer->st_volume_id) ) ||
>> + __clear_user(&buffer->__spares, sizeof(buffer->__spares)))
>> + return -EFAULT;
>> + return 0;
>> +}
>> +
>> +/*
>> + * System call to get extended stats by path
>> + */
>> +SYSCALL_DEFINE5(xstat,
>> + int, dfd, const char __user *, filename, unsigned, flags,
>> + unsigned int, mask, struct xstat __user *, buffer)
>> +{
>> + struct kstat stat;
>> + int error;
>> +
>> + error = xstat_get_params(mask, buffer, &stat);
>> + if (error != 0)
>> + return error;
>> + error = vfs_xstat(dfd, filename, flags, &stat);
>> + if (error)
>> + return error;
>> + return xstat_set_result(&stat, buffer);
>> +}
>> +
>> +/*
>> + * System call to get extended stats by file descriptor
>> + */
>> +SYSCALL_DEFINE4(fxstat, unsigned int, fd, unsigned int, flags,
>> + unsigned int, mask, struct xstat __user *, buffer)
>> +{
>> + struct kstat stat;
>> + int error;
>> +
>> + error = xstat_get_params(mask, buffer, &stat);
>> + if (error < 0)
>> + return error;
>> + stat.query_flags = flags;
>> + error = vfs_fxstat(fd, &stat);
>> + if (error)
>> + return error;
>> + return xstat_set_result(&stat, buffer);
>> +}
>> +
>> /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
>> void __inode_add_bytes(struct inode *inode, loff_t bytes)
>> {
>> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
>> index f550f89..faa9e5d 100644
>> --- a/include/linux/fcntl.h
>> +++ b/include/linux/fcntl.h
>> @@ -47,6 +47,7 @@
>> #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
>> #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */
>> #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */
>> +#define AT_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */
>>
>> #ifdef __KERNEL__
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 8de6755..ec6c62e 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1467,6 +1467,7 @@ struct super_block {
>>
>> char s_id[32]; /* Informational name */
>> u8 s_uuid[16]; /* UUID */
>> + unsigned char s_volume_id[16]; /* Volume identifier */
>>
>> void *s_fs_info; /* Filesystem private info */
>> unsigned int s_max_links;
>> @@ -2470,6 +2471,7 @@ extern const struct inode_operations page_symlink_inode_operations;
>> extern int generic_readlink(struct dentry *, char __user *, int);
>> extern void generic_fillattr(struct inode *, struct kstat *);
>> extern int vfs_getattr(struct vfsmount *, struct dentry *, struct kstat *);
>> +extern int vfs_xgetattr(struct vfsmount *, struct dentry *, struct kstat *);
>> void __inode_add_bytes(struct inode *inode, loff_t bytes);
>> void inode_add_bytes(struct inode *inode, loff_t bytes);
>> void inode_sub_bytes(struct inode *inode, loff_t bytes);
>> @@ -2482,6 +2484,8 @@ extern int vfs_stat(const char __user *, struct kstat *);
>> extern int vfs_lstat(const char __user *, struct kstat *);
>> extern int vfs_fstat(unsigned int, struct kstat *);
>> extern int vfs_fstatat(int , const char __user *, struct kstat *, int);
>> +extern int vfs_xstat(int, const char __user *, int, struct kstat *);
>> +extern int vfs_xfstat(unsigned int, struct kstat *);
>>
>> extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
>> unsigned long arg);
>> diff --git a/include/linux/stat.h b/include/linux/stat.h
>> index 611c398..0ff561a 100644
>> --- a/include/linux/stat.h
>> +++ b/include/linux/stat.h
>> @@ -3,6 +3,7 @@
>>
>> #ifdef __KERNEL__
>>
>> +#include <linux/types.h>
>> #include <asm/stat.h>
>>
>> #endif
>> @@ -46,6 +47,117 @@
>>
>> #endif
>>
>> +/*
>> + * Query request/result mask
>> + *
>> + * Bits should be set in request_mask to request particular items when calling
>> + * xstat() or fxstat().
>> + *
>> + * The bits in st_mask may or may not be set upon return, in part depending on
>> + * what was set in the mask argument:
>> + *
>> + * - if not available at all, the bit will be cleared before returning and the
>> + * field will be cleared; otherwise,
>> + *
>> + * - if AT_FORCE_ATTR_SYNC is set, then the datum will be synchronised to the
>> + * server and the field and bit will be set on return; otherwise,
>> + *
>> + * - if explicitly requested, the datum will be synchronised to a server or
>> + * other medium if out of date before being returned, and the bit will be set
>> + * on return; otherwise,
>> + *
>> + * - if not requested, but available in approximate form without any effort, it
>> + * will be filled in anyway, and the bit will be set upon return (it might
>> + * not be up to date, however, and no attempt will be made to synchronise the
>> + * internal state first); otherwise,
>> + *
>> + * - the field and the bit will be cleared before returning.
>> + *
>> + * Items in XSTAT_BASIC_STATS may be marked unavailable on return, but they
>> + * will have a value installed for compatibility purposes so that stat() and
>> + * co. can be emulated in userspace.
>> + */
>> +#define XSTAT_MODE 0x00000001U /* want/got st_mode */
>> +#define XSTAT_NLINK 0x00000002U /* want/got st_nlink */
>> +#define XSTAT_UID 0x00000004U /* want/got st_uid */
>> +#define XSTAT_GID 0x00000008U /* want/got st_gid */
>> +#define XSTAT_RDEV 0x00000010U /* want/got st_rdev */
>> +#define XSTAT_ATIME 0x00000020U /* want/got st_atime */
>> +#define XSTAT_MTIME 0x00000040U /* want/got st_mtime */
>> +#define XSTAT_CTIME 0x00000080U /* want/got st_ctime */
>> +#define XSTAT_INO 0x00000100U /* want/got st_ino */
>> +#define XSTAT_SIZE 0x00000200U /* want/got st_size */
>> +#define XSTAT_BLOCKS 0x00000400U /* want/got st_blocks */
>> +#define XSTAT_BASIC_STATS 0x000007ffU /* the stuff in the normal stat struct */
>> +#define XSTAT_IOC_FLAGS 0x00000800U /* want/got FS_IOC_GETFLAGS */
>> +#define XSTAT_BTIME 0x00001000U /* want/got st_btime */
>> +#define XSTAT_GEN 0x00002000U /* want/got st_gen */
>> +#define XSTAT_VERSION 0x00004000U /* want/got st_version */
>> +#define XSTAT_VOLUME_ID 0x00008000U /* want/got st_volume_id */
>> +#define XSTAT_ALL_STATS 0x0000ffffU /* all supported stats */
>> +
>> +/*
>> + * Extended stat structures
>> + */
>> +struct xstat_dev {
>> + uint32_t major, minor;
>> +};
>> +
>> +struct xstat_time {
>> + int64_t tv_sec;
>> + uint32_t tv_nsec;
>> + uint32_t tv_granularity; /* time granularity (in nS) */
>> +};
>> +
>> +struct xstat {
>> + uint32_t st_mask; /* what results were written */
>> + uint32_t st_mode; /* file mode */
>> + uint32_t st_nlink; /* number of hard links */
>> + uint32_t st_uid; /* user ID of owner */
>> + uint32_t st_gid; /* group ID of owner */
>> + uint32_t st_information; /* information about the file */
>> + uint32_t st_ioc_flags; /* as FS_IOC_GETFLAGS */
>> + uint32_t st_blksize; /* optimal size for filesystem I/O */
>> + struct xstat_dev st_rdev; /* device ID of special file */
>> + struct xstat_dev st_dev; /* ID of device containing file */
>> + struct xstat_time st_atime; /* last access time */
>> + struct xstat_time st_btime; /* file creation time */
>> + struct xstat_time st_ctime; /* last attribute change time */
>> + struct xstat_time st_mtime; /* last data modification time */
>> + uint64_t st_ino; /* inode number */
>> + uint64_t st_size; /* file size */
>> + uint64_t st_blocks; /* number of 512-byte blocks allocated */
>> + uint64_t st_gen; /* inode generation number */
>> + uint64_t st_version; /* data version number */
>> + uint8_t st_volume_id[16]; /* volume identifier */
>> + uint64_t __spares[11]; /* spare space for future expansion */
>> +};
>> +
>> +/*
>> + * Flags to be found in st_information
>> + *
>> + * These give information about the features or the state of a file that might
>> + * be of use to ordinary userspace programs such as GUIs or ls rather than
>> + * specialised tools.
>> + *
>> + * Additional information may be found in st_ioc_flags and we try not to
>> + * overlap with it.
>> + */
>> +#define XSTAT_INFO_ENCRYPTED 0x00000001U /* File is encrypted */
>> +#define XSTAT_INFO_TEMPORARY 0x00000002U /* File is temporary (NTFS/CIFS) */
>> +#define XSTAT_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */
>> +#define XSTAT_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */
>> +#define XSTAT_INFO_REMOTE 0x00000010U /* File is remote */
>> +#define XSTAT_INFO_OFFLINE 0x00000020U /* File is offline (CIFS) */
>> +#define XSTAT_INFO_AUTOMOUNT 0x00000040U /* Dir is automount trigger */
>> +#define XSTAT_INFO_AUTODIR 0x00000080U /* Dir provides unlisted automounts */
>> +#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U /* File has non-system ownership details */
>> +#define XSTAT_INFO_HAS_ACL 0x00000200U /* File has an ACL of some sort */
>> +#define XSTAT_INFO_REPARSE_POINT 0x00000400U /* File is reparse point (NTFS/CIFS) */
>> +#define XSTAT_INFO_HIDDEN 0x00000800U /* File is marked hidden (DOS+) */
>> +#define XSTAT_INFO_SYSTEM 0x00001000U /* File is marked system (DOS+) */
>> +#define XSTAT_INFO_ARCHIVE 0x00002000U /* File is marked archive (DOS+) */
>> +
>> #ifdef __KERNEL__
>> #define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO)
>> #define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO)
>> @@ -60,6 +172,12 @@
>> #include <linux/time.h>
>>
>> struct kstat {
>> + u32 query_flags; /* operational flags */
>> +#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC)
>> + u32 request_mask; /* what fields the user asked for */
>> + u32 result_mask; /* what fields the user got */
>> + u32 information;
>> + u32 ioc_flags; /* inode flags (FS_IOC_GETFLAGS) */
>> u64 ino;
>> dev_t dev;
>> umode_t mode;
>> @@ -67,14 +185,18 @@ struct kstat {
>> uid_t uid;
>> gid_t gid;
>> dev_t rdev;
>> + unsigned int tv_granularity; /* granularity of times (in nS) */
>> loff_t size;
>> - struct timespec atime;
>> + struct timespec atime;
>> struct timespec mtime;
>> struct timespec ctime;
>> + struct timespec btime; /* file creation time */
>> unsigned long blksize;
>> unsigned long long blocks;
>> + u64 gen; /* inode generation */
>> + u64 version; /* data version */
>> + unsigned char volume_id[16]; /* volume identifier */
>> };
>>
>> #endif
>> -
>> #endif
>> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
>> index 3de3acb..ff9f8d9 100644
>> --- a/include/linux/syscalls.h
>> +++ b/include/linux/syscalls.h
>> @@ -45,6 +45,8 @@ struct shmid_ds;
>> struct sockaddr;
>> struct stat;
>> struct stat64;
>> +struct xstat_parameters;
>> +struct xstat;
>> struct statfs;
>> struct statfs64;
>> struct __sysctl_args;
>> @@ -858,4 +860,9 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
>> unsigned long riovcnt,
>> unsigned long flags);
>>
>> +asmlinkage long sys_xstat(int dfd, const char __user *path, unsigned flags,
>> + unsigned mask, struct xstat __user *buffer);
>> +asmlinkage long sys_fxstat(unsigned fd, unsigned flags,
>> + unsigned mask, struct xstat __user *buffer);
>> +
>> #endif
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Cheers, Andreas

2012-04-26 21:55:25

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Roland McGrath <[email protected]> wrote:

> > I've no particular attachment to the name 'xstat'. If you'd prefer
> > 'statx' I could go for that.
>
> I prefer something other than xstat and statx(at) seems acceptable enough.
> What I'd really prefer is a name that is less meaninglessly arcane,
> but I haven't thought of any good ones.

fileinfoat() perhaps? I think stat*at() is better, though, as people are used
to the stat function family.

David

2012-04-26 14:28:37

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
> Steve French <[email protected]> wrote:
>
> > I also would prefer that we simply treat the time granularity as part
> > of the superblock (mounted volume) ie returned on fstat rather than on
> > every stat of the filesystem. For cifs mounts we could conceivably
> > have different time granularity (1 or 2 second) on mounts to old
> > servers rather than 100 nanoseconds.
>
> The question is whether you want to have to do a statfs in addition to a stat?
> I suppose you can potentially cache the statfs based on device number.
>
> That said, there are cases where caching filesystem-level info based on i_dev
> doesn't work. OpenAFS springs to mind as that only has one superblock and
> thus one set of device numbers, but keeps all the inodes for all the different
> volumes it may have mounted there.
>
> I don't know whether this would be a problem for CIFS too - say on a windows
> server you fabricate P:, for example, by joining together several filesystems
> (with junctions?). How does this appear on a Linux client when it steps from
> one filesystem to another within a mounted share?

In the NFS case we do try to preserve filesystem boundaries as well as
we can--the protocol has an fsid field and the client creates a new
mount each time it sees it change. And the protocol defines time_delta
as a per-filesystem attribute (though, somewhat hilariously, there's
also a per-filesystem "homogeneous" attribute that a server can clear to
indicate the per-filesystem attributes might actually vary within the
filesystem.)

--b.

2012-04-26 14:54:27

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 9:25 AM, David Howells <[email protected]> wrote:
> Steve French <[email protected]> wrote:
>
>> Would it be better to make the stable vs volatile inode number an attribute
>> of the volume ?or something returned by the proposed xstat?
>
> I'm not sure what you mean by a stable vs a volatile inode number.

Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
unique identifier, but in the case of CIFS some old servers don't support the
calls which return inode numbers (or don't return them for all file system
types, Windows FAT?) so in these cases cifs has to create inode
numbers on the fly
on the client. inode numbers created on the client are not "stable" they
can change on unmount/remount (which can cause problems for backup
applications).

Similarly NFSv4 does not require that servers always return stable inode numbers
(that will never change) and introduced a concept of "volatile file handle."
We have run into this in two cases (there are probably more) -
Specialized NFS servers
for HPC which deal with lots of transient inodes, and second those for servers
which base there inode number on path (Windows NFS?). See
http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
or the NFSv4 RFC.

Basically the question is whether it is worth reporting a flag on the
call which returns
the inode number to indicate that the inode number is "stable" (would not change
on reboot or reconnection) or "volatile." Since the majority of NFS
and SMB2 servers
can return stable inode numbers, I don't feel strongly about the need
for an indicator
of "stable" vs. "volatile" but I mention it because backup and
migration applications
mention this (if inode numbers are volatile, they may have to check
for hardlinks differently
for example)

>> > Should things like the Windows Archive, Hidden and System bits be handled
>> > through IOC flags, perhaps expanded to 64-bits?
>>
>> Today I export these through an psuedo-xattr in cifs.ko, I am curious how
>> NTFS and FAT export these on linux.
>
> NTFS: Not at all.
>
> FAT: The hidden bit causes the filename to get a dot prepended (and nothing
> else is noted).
>
>> > Autofs, ntfs, btrfs, ...
>>
>> Given the overlap in optional attributes between the network
>> protocol and local NTFS (and ReFS and to a lesser extent FAT)
>> I would expect cifs.ko and the ntfs implementations
>> info to map pretty closely.
>
> Yep. ?I wasn't going to do more filesystems till we'd finished arguing about
> the basic arrangement of things in struct xstat.

makes sense

>> > Handle remote filesystems being offline and indicate this with
>> > XSTAT_INFO_OFFLINE.
>>
>> You already have support for an indicator for offline files (HSM),
>
> HSM

HSM is the more general case of two tiered data (disk vs. tape)

en.wikipedia.org/wiki/Hierarchical_storage_management

in the simplest case on "disk" (fast) vs. moved to tape (slow to retrieve)

>> would XSTAT_INFO_OFFLINE be intended for the case
>> where the network session to the server is disconnected
>> (and in which you case the application does not want to reconnect)?
>
> Hmmm... ?Interesting question. ?Both NTFS and CIFS have an offline attribute
> (which is where I originally got this from) - but should I have a separate
> indicator to indicate the client can't access a server over a network
> (ie. we've gone to disconnected operation on this file)? ?E.g. should there be
> a XSTAT_INFO_DISCONNECTED too?

my reaction is no, since it adds complexity. If you do a stat on a disconnected
volume (where the network is temporarily down) reconnection will be attempted.
If reconnection fails then the xstat will either fail or be retried forever
depending on the value of "hard" vs. "soft" mount flag.

--
Thanks,

Steve

2012-04-27 15:11:25

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Fri, Apr 27, 2012 at 11:13:06PM +1000, Dave Chinner wrote:
> Right now it is, but there's ben patches in the past to introduce
> project quotas to ext4. That didn't go far because it was done in a
> way that was semantically different to XFS (for no reason that I
> could understand) and nobody wanted two different sets of semantics
> for the "same" feature. The most common use of project quotas is to
> implement sub-tree quotas,

(Though it's also useful as a way to do safe subtree NFS exports).

--b.

> which is probably of more interest to
> btrfs folks as it is an exact match for per-subvolume quotas.
>
> So, yes, I do see it as something generically useful - it's a
> feature that a lot of people use XFS specifically for....
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2012-04-26 14:16:43

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Roland McGrath <[email protected]> wrote:

> statx seems like a better family of names. I also think it's worthwhile to
> see if the interface can be made to more closely match the AIX precedent.

I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very
closely, at least from a syscall interface point of view. We really need the
AT_* flags mask to be compatible with the other Linux syscalls and the length
parameter that I originally had got argued out of existence. I would also
like to make it so that there aren't different 32-bit and 64-bit interfaces to
the kernel - though that means a burden on glibc/uClibc/etc., I guess.

I do also want to be able to pass a mask of what we're actually interested in
- but that's not part of the AIX interface.

I also like the idea of having a larger buffer with the ability to return
extra info (such as security label xattrs), but I was told it was a poor idea,
so that got taken out.

David

2012-04-19 14:07:55

[permalink] [raw]

Subject: [PATCH 6/6] xstat: eCryptFS: Return extended attributes

Return extended attributes from the eCryptFS filesystem, dredged up from the
lower filesystem. XSTAT_INFO_ENCRYPTED is set on the files whose cryptography
is handled by eCryptFS.

Possibly eCryptFS should also set FS_COMPR_FL on its compressed files.

Signed-off-by: David Howells <[email protected]>
---

fs/ecryptfs/inode.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index ab35b11..62865e9 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -1060,13 +1060,23 @@ int ecryptfs_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat lower_stat;
int rc;

- rc = vfs_getattr(ecryptfs_dentry_to_lower_mnt(dentry),
- ecryptfs_dentry_to_lower(dentry), &lower_stat);
+ lower_stat.query_flags = stat->query_flags;
+ lower_stat.request_mask = stat->request_mask | XSTAT_BLOCKS;
+ rc = vfs_xgetattr(ecryptfs_dentry_to_lower_mnt(dentry),
+ ecryptfs_dentry_to_lower(dentry), &lower_stat);
if (!rc) {
fsstack_copy_attr_all(dentry->d_inode,
ecryptfs_inode_to_lower(dentry->d_inode));
generic_fillattr(dentry->d_inode, stat);
stat->blocks = lower_stat.blocks;
+ stat->result_mask = lower_stat.result_mask;
+ stat->information = lower_stat.information;
+ stat->information |= XSTAT_INFO_ENCRYPTED;
+ stat->gen = lower_stat.gen;
+ stat->version = lower_stat.version;
+ stat->ioc_flags = lower_stat.ioc_flags;
+ memcpy(&stat->volume_id, lower_stat.volume_id,
+ sizeof(stat->volume_id));
}
return rc;
}

2012-04-26 22:05:53

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

> What if the xstat() and struct xstat eventually becomes what userspace
> uses as stat() (as a wrapper) and struct stat (if such a thing is
> possible with glibc versioning)?

It's certainly possible with symbol versioning, though it seems much more
likely that we'd stick with the existing struct stat and stat* interfaces
and only have the implementation using statx underneath (e.g. for new
machines or kernel ABIs where the kernel stops providing any calls except
for statxat), at least for the foreseeable future.

> Do older programs that think they're using stat() and don't know about
> the extra fields available expect to see a useful value in st_ino?

POSIX requires that st_ino have a useful value for the standard *stat calls.

Thanks,
Roland

2012-04-27 19:31:10

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On 2012-04-27, at 7:13 AM, Dave Chinner wrote:
> Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined
> at the bottom of the file.
>
> Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly
> generic - they are for indicating that files are to be avoided for
> defrag or backup purposes, the prealloc bit indicates that fallocate
> has been used to reserve space on the inode (finding files that space
> can be punched out of safely), and so on.

There is already the FS_NODUMP_FL in the standard FS_IOC_GETFLAGS ioctl
and I expect this to be in statxat() also. In ext4 there was also an
EXT4_EOFBLOCKS_FL added for inodes with fallocate'd data beyond EOF,
but Eric thought it was a pain to maintain and it has been deprecated
in ext4 and e2fsprogs recently.

> Currently these things are queried and manipulated by ioctls
> (XFS_IOC_FSX[GS]ETATTR) along with extent size hints, project
> quotas, etc. but I think there's some wider use for many of the
> flags, which is why I was asking is there's any thought to this sort
> of flag being exposed by the VFS.
>
> Historically the flags exposed by the VFS are those used by extN - I
> see little reason why we should favour one filesystem's flags over
> any others in an extended stat interface if they are generically
> useful....

Sure, they started as ext4 flags because the "lsattr" and "chattr"
tools were using this ioctl/flags, but have become more generic in
recent years. FS_NOTAIL_FL was added for Reiserfs, and FS_NOCOW_FL
was added for another filesystem (maybe Btrfs?). I'm not against
adding more flags here that are generically useful, and recommended
that statxat() have a 64-bit st_ioc_flags, since there are already
22 FS_*_FL flags defined today.

>> Either you can add some of them to the ioc flags (which may be
>> impractical, I grant you) or we'd have to add an arbitrary fs-type
>> specific field and specify the host fs (the provision of which might
>> not be a bad idea in and of itself) to tell userspace how to interpret them.
>
> Well, that's the complexity, isn't it. I have no good answer to
> that...
>
>>> 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...
>>
>> Yeah... Not representable by one number. You'd have to unset a
>> flag to say you were providing this information.
>>
>> However, providing a whole bunch of hints about I/O characteristics
>> is probably beyond this syscall - especially if it isn't constant
>> over the length of a file. That's specialist knowledge that most
>> applications don't need to know.
>> Having a generic way to retrieve it, though, may be a good idea.
>
> We're continually talking about applications giving us usage hints
> on what IO they are going to do so the storage can optimise the IO.
> IO is still a GIGO problem, though, and the idea of geometry hints
> is to enable us to tell the application to do well formed IO. i.e.
> less garbage.
>
> XFS has ioctls to expose filesystem geometry, optimal IO sizes, the
> alignment limits for direct IO, etc, and they are very useful to
> applications that care about high performance IO. A lot of this can
> be distilled down to a simple set of geometries, and generally
> speaking they don't change mid way through a file....
>
>> OTOH, there's plenty of uncommitted space, so if we can condense
>> the hints down to something small, we could perhaps add it later -
>> but from your paragraph above, it doesn't sound like it'll be small.
>
> Allocation block size, minimum sane IO size (to avoid page cache RMW
> cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit),
> optimal IO size for bandwidth (e.g. stripe width). I don't think
> there's much more than that which will be really usable by
> applications.

I think this is a minimal set that makes sense, and is manageable for
both the interface and for users. Even if it isn't 100% correct for
every file of every filesystem, it still makes sense for many systems.
I'd suggest st_frsize (like BSD statvfs() f_frsize) would be the
minimum fragment or page size, st_iosize (BSD f_iosize) could be
the optimal IO size, and "st_stripesize" for the minimum preferred RAID/chunk size.

One could argue that "st_blksize" is used for the "optimal IO size"
on Linux today, but this is an overloaded term. It _appears_ to
represent the filesystem blocksize, which it usually is not, and on
BSD st_bsize means the minimum blocksize and has a confusingly
similar name. Since any application using this API needs to do some
extra coding already, we may as well give the structure members good
names that are not ambiguous.

>>> 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....
>>
>> Is this an XFS only thing? If so, can it be generalised?
>
> Right now it is, but there's been patches in the past to introduce
> project quotas to ext4. That didn't go far because it was done in a
> way that was semantically different to XFS (for no reason that I
> could understand) and nobody wanted two different sets of semantics
> for the "same" feature. The most common use of project quotas is to
> implement sub-tree quotas, which is probably of more interest to
> btrfs folks as it is an exact match for per-subvolume quotas.
>
> So, yes, I do see it as something generically useful - it's a
> feature that a lot of people use XFS specifically for....

I'd agree. There was the tree quota project for ext4, and I've also
heard this is available in other filesystems.

Cheers, Andreas

2012-04-26 15:26:03

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

T24gVGh1LCAyMDEyLTA0LTI2IGF0IDA5OjU0IC0wNTAwLCBTdGV2ZSBGcmVuY2ggd3JvdGU6DQo+
IE9uIFRodSwgQXByIDI2LCAyMDEyIGF0IDk6MjUgQU0sIERhdmlkIEhvd2VsbHMgPGRob3dlbGxz
QHJlZGhhdC5jb20+IHdyb3RlOg0KPiA+IFN0ZXZlIEZyZW5jaCA8c21mcmVuY2hAZ21haWwuY29t
PiB3cm90ZToNCj4gPg0KPiA+PiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gbWFrZSB0aGUgc3RhYmxl
IHZzIHZvbGF0aWxlIGlub2RlIG51bWJlciBhbiBhdHRyaWJ1dGUNCj4gPj4gb2YgdGhlIHZvbHVt
ZSAgb3Igc29tZXRoaW5nIHJldHVybmVkIGJ5IHRoZSBwcm9wb3NlZCB4c3RhdD8NCj4gPg0KPiA+
IEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IGEgc3RhYmxlIHZzIGEgdm9sYXRpbGUgaW5v
ZGUgbnVtYmVyLg0KPiANCj4gQm90aCBORlMgYW5kIENJRlMgKGFuZCBTTUIyKSBjYW4gcmV0dXJu
IGlub2RlIG51bWJlcnMgb3IgZXF1aXZhbGVudA0KPiB1bmlxdWUgaWRlbnRpZmllciwgYnV0IGlu
IHRoZSBjYXNlIG9mIENJRlMgc29tZSBvbGQgc2VydmVycyBkb24ndCBzdXBwb3J0IHRoZQ0KPiBj
YWxscyB3aGljaCByZXR1cm4gaW5vZGUgbnVtYmVycyAob3IgZG9uJ3QgcmV0dXJuIHRoZW0gZm9y
IGFsbCBmaWxlIHN5c3RlbQ0KPiB0eXBlcywgV2luZG93cyBGQVQ/KSBzbyBpbiB0aGVzZSBjYXNl
cyBjaWZzIGhhcyB0byBjcmVhdGUgaW5vZGUNCj4gbnVtYmVycyBvbiB0aGUgZmx5DQo+IG9uIHRo
ZSBjbGllbnQuICAgaW5vZGUgbnVtYmVycyBjcmVhdGVkIG9uIHRoZSBjbGllbnQgYXJlIG5vdCAi
c3RhYmxlIiB0aGV5DQo+IGNhbiBjaGFuZ2Ugb24gdW5tb3VudC9yZW1vdW50ICh3aGljaCBjYW4g
Y2F1c2UgcHJvYmxlbXMgZm9yIGJhY2t1cA0KPiBhcHBsaWNhdGlvbnMpLg0KPiANCj4gU2ltaWxh
cmx5IE5GU3Y0IGRvZXMgbm90IHJlcXVpcmUgdGhhdCBzZXJ2ZXJzIGFsd2F5cyByZXR1cm4gc3Rh
YmxlIGlub2RlIG51bWJlcnMNCj4gKHRoYXQgd2lsbCBuZXZlciBjaGFuZ2UpIGFuZCBpbnRyb2R1
Y2VkIGEgY29uY2VwdCBvZiAidm9sYXRpbGUgZmlsZSBoYW5kbGUuIg0KPiBXZSBoYXZlIHJ1biBp
bnRvIHRoaXMgaW4gdHdvIGNhc2VzICh0aGVyZSBhcmUgcHJvYmFibHkgbW9yZSkgLQ0KPiBTcGVj
aWFsaXplZCBORlMgc2VydmVycw0KPiBmb3IgSFBDIHdoaWNoIGRlYWwgd2l0aCBsb3RzIG9mIHRy
YW5zaWVudCBpbm9kZXMsIGFuZCBzZWNvbmQgdGhvc2UgZm9yIHNlcnZlcnMNCj4gd2hpY2ggYmFz
ZSB0aGVyZSBpbm9kZSBudW1iZXIgb24gcGF0aCAoV2luZG93cyBORlM/KS4gIFNlZQ0KPiBodHRw
Oi8vZG9jcy5vcmFjbGUuY29tL2NkL0UxOTA4Mi0wMS84MTktMTYzNC9yZnNyZWZlci0xMzcvaW5k
ZXguaHRtbA0KPiBvciB0aGUgTkZTdjQgUkZDLg0KPiANCj4gQmFzaWNhbGx5IHRoZSBxdWVzdGlv
biBpcyB3aGV0aGVyIGl0IGlzIHdvcnRoIHJlcG9ydGluZyBhIGZsYWcgb24gdGhlDQo+IGNhbGwg
d2hpY2ggcmV0dXJucw0KPiB0aGUgaW5vZGUgbnVtYmVyIHRvIGluZGljYXRlIHRoYXQgdGhlIGlu
b2RlIG51bWJlciBpcyAic3RhYmxlIiAod291bGQgbm90IGNoYW5nZQ0KPiBvbiByZWJvb3Qgb3Ig
cmVjb25uZWN0aW9uKSBvciAidm9sYXRpbGUuIiAgICBTaW5jZSB0aGUgbWFqb3JpdHkgb2YgTkZT
DQo+IGFuZCBTTUIyIHNlcnZlcnMNCj4gY2FuIHJldHVybiBzdGFibGUgaW5vZGUgbnVtYmVycywg
SSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoZSBuZWVkDQo+IGZvciBhbiBpbmRpY2F0b3IN
Cj4gb2YgInN0YWJsZSIgdnMuICJ2b2xhdGlsZSIgYnV0IEkgbWVudGlvbiBpdCBiZWNhdXNlIGJh
Y2t1cCBhbmQNCj4gbWlncmF0aW9uIGFwcGxpY2F0aW9ucw0KPiBtZW50aW9uIHRoaXMgKGlmIGlu
b2RlIG51bWJlcnMgYXJlIHZvbGF0aWxlLCB0aGV5IG1heSBoYXZlIHRvIGNoZWNrDQo+IGZvciBo
YXJkbGlua3MgZGlmZmVyZW50bHkNCj4gZm9yIGV4YW1wbGUpDQoNCkkgZG9uJ3QgdW5kZXJzdGFu
ZC4gSWYgdGhlIGZpbGVzeXN0ZW0gZG9lc24ndCBzdXBwb3J0IHJlYWwgaW5vZGUNCm51bWJlcnMs
IHRoZW4gd2h5IHJlcG9ydCB0aGVtIGF0IGFsbD8gV2hhdCB1c2Ugd291bGQgYW4gYXBwbGljYXRp
b24gaGF2ZQ0KZm9yIGFuIGlub2RlIG51bWJlciB0aGF0IGNhbid0IGJlIHVzZWQgdG8gaWRlbnRp
ZnkgaGFyZCBsaW5rZWQgZmlsZXM/DQoNCkNoZWVycw0KICBUcm9uZA0KLS0gDQpUcm9uZCBNeWts
ZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xl
YnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=

2012-04-28 00:59:05

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

On Fri, Apr 27, 2012 at 01:31:07PM -0600, Andreas Dilger wrote:
> On 2012-04-27, at 7:13 AM, Dave Chinner wrote:
> > Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined
> > at the bottom of the file.
> >
> > Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly
> > generic - they are for indicating that files are to be avoided for
> > defrag or backup purposes, the prealloc bit indicates that fallocate
> > has been used to reserve space on the inode (finding files that space
> > can be punched out of safely), and so on.
>
> There is already the FS_NODUMP_FL in the standard FS_IOC_GETFLAGS ioctl
> and I expect this to be in statxat() also.

I forgot that was one of the generic flags :/

> In ext4 there was also an
> EXT4_EOFBLOCKS_FL added for inodes with fallocate'd data beyond EOF,
> but Eric thought it was a pain to maintain and it has been deprecated
> in ext4 and e2fsprogs recently.

I'd think that flag is more of a "filesystem implementation
specific" flag than a general "this file contained persistent
preallocation" flag, which is essentially what the XFS flag says.
XFS uses in various ways to optimise extent management on the file
(e.g. don't truncate extents past EOF when closing the file), but it
is not specific to one particular aspect of the preallocation
implementation.

> >> OTOH, there's plenty of uncommitted space, so if we can condense
> >> the hints down to something small, we could perhaps add it later -
> >> but from your paragraph above, it doesn't sound like it'll be small.
> >
> > Allocation block size, minimum sane IO size (to avoid page cache RMW
> > cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit),
> > optimal IO size for bandwidth (e.g. stripe width). I don't think
> > there's much more than that which will be really usable by
> > applications.
>
> I think this is a minimal set that makes sense, and is manageable for
> both the interface and for users. Even if it isn't 100% correct for
> every file of every filesystem, it still makes sense for many systems.

That's the aim, isn't it? To expose what is useful to the majority
in a simple manner?

> I'd suggest st_frsize (like BSD statvfs() f_frsize) would be the
> minimum fragment or page size, st_iosize (BSD f_iosize) could be
> the optimal IO size, and "st_stripesize" for the minimum preferred RAID/chunk size.

Personally, I think those names are, well, terribly lacking in
obviousness. Something more along the lines of:

st_blksize - file block size
st_alloc_blksize - allocation block size/alignment
st_small_io_size - IO size/alignment that avoids
filesystem/page cache RMW
st_preferred_io_size - preferred IO size for general
usage.
st_large_io_size - IO size/alignment for high
bandwidth sequential IO

With the aim that applications tend to use st_preferred_io_size for
all general IO (i.e. the default), st_small_io_size for small IO,
IOPS intensive workloads, and st_large_io_size for writing large
chunks of sequential data.

> One could argue that "st_blksize" is used for the "optimal IO size"
> on Linux today, but this is an overloaded term. It _appears_ to
> represent the filesystem blocksize, which it usually is not, and on
> BSD st_bsize means the minimum blocksize and has a confusingly
> similar name. Since any application using this API needs to do some
> extra coding already, we may as well give the structure members good
> names that are not ambiguous.

Well said - I couldn't have stated the case better myself. ;)

Cheers,

Dave.

--
Dave Chinner
[email protected]

2012-04-26 14:27:03

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Steve French <[email protected]> wrote:

> Would it be better to make the stable vs volatile inode number an attribute
> of the volume or something returned by the proposed xstat?

I'm not sure what you mean by a stable vs a volatile inode number.

> > Should things like the Windows Archive, Hidden and System bits be handled
> > through IOC flags, perhaps expanded to 64-bits?
>
> Today I export these through an psuedo-xattr in cifs.ko, I am curious how
> NTFS and FAT export these on linux.

NTFS: Not at all.

FAT: The hidden bit causes the filename to get a dot prepended (and nothing
else is noted).

> > Autofs, ntfs, btrfs, ...
>
> Given the overlap in optional attributes between the network
> protocol and local NTFS (and ReFS and to a lesser extent FAT)
> I would expect cifs.ko and the ntfs implementations
> info to map pretty closely.

Yep. I wasn't going to do more filesystems till we'd finished arguing about
the basic arrangement of things in struct xstat.

> > Handle remote filesystems being offline and indicate this with
> > XSTAT_INFO_OFFLINE.
>
> You already have support for an indicator for offline files (HSM),

HSM?

> would XSTAT_INFO_OFFLINE be intended for the case
> where the network session to the server is disconnected
> (and in which you case the application does not want to reconnect)?

Hmmm... Interesting question. Both NTFS and CIFS have an offline attribute
(which is where I originally got this from) - but should I have a separate
indicator to indicate the client can't access a server over a network
(ie. we've gone to disconnected operation on this file)? E.g. should there be
a XSTAT_INFO_DISCONNECTED too?

David

2012-04-19 14:07:06

[permalink] [raw]

Subject: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

Add a pair of system calls to make extended file stats available, including
file creation time, inode version and data version where available through the
underlying filesystem.

The idea was initially proposed as a set of xattrs that could be retrieved with
getxattr(), but the general preferance proved to be for new syscalls with an
extended stat structure.

This has a number of uses:

(1) Creation time: The SMB protocol carries the creation time, which could be
exported by Samba, which will in turn help CIFS make use of FS-Cache as
that can be used for coherency data.

This is also specified in NFSv4 as a recommended attribute and could be
exported by NFSD [Steve French].

(2) Lightweight stat: Ask for just those details of interest, and allow a
netfs (such as NFS) to approximate anything not of interest, possibly
without going to the server [Trond Myklebust, Ulrich Drepper].

(3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its
cached attributes are up to date [Trond Myklebust].

(4) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd
Schubert].

(5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar].

Can also be used to modify fill_post_wcc() in NFSD which retrieves
i_version directly, but has just called vfs_getattr(). It could get it
from the kstat struct if it used vfs_xgetattr() instead.

(6) BSD stat compatibility: Including more fields from the BSD stat such as
creation time (st_btime) and inode generation number (st_gen) [Jeremy
Allison, Bernd Schubert].

(7) Extra coherency data may be useful in making backups [Andreas Dilger].

(8) Allow the filesystem to indicate what it can/cannot provide: A filesystem
can now say it doesn't support a standard stat feature if that isn't
available, so if, for instance, inode numbers or UIDs don't exist...

(9) Make the fields a consistent size on all arches and make them large.

(10) Store a 16-byte volume ID in the superblock that can be returned in struct
xstat [Steve French].

(11) Include granularity fields in the time data to indicate the granularity of
each of the times (NFSv4 time_delta) [Steve French].

(12) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.

(13) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
Michael Kerrisk].

(14) Spare space, request flags and information flags are provided for future
expansion.

The following structures are defined for the use of these new system calls:

struct xstat_dev {
uint32_t major, minor;
};

struct xstat_time {
uint64_t tv_sec;
uint32_t tv_nsec;
uint32_t tv_granularity;
};

struct xstat {
uint32_t st_mask;
uint32_t st_mode;
uint32_t st_nlink;
uint32_t st_uid;
uint32_t st_gid;
uint32_t st_information;
uint32_t st_ioc_flags;
uint32_t st_blksize;
struct xstat_dev st_rdev;
struct xstat_dev st_dev;
struct xstat_time st_atime;
struct xstat_time st_btime;
struct xstat_time st_ctime;
struct xstat_time st_mtime;
uint64_t st_ino;
uint64_t st_size;
uint64_t st_blocks;
uint64_t st_gen;
uint64_t st_version;
uint8_t st_volume_id[16];
uint64_t __spares[11];
};

where st_information is local system information about the file, st_btime is
the file creation time, st_gen is the inode generation (i_generation),
st_data_version is the data version number (i_version), st_ioc_flags is the
flags from FS_IOC_GETFLAGS, st_volume_id is where the volume identified is
stored, st_result_mask is a bitmask indicating the data provided and __spares[]
are where as-yet undefined fields can be placed.

The defined bits in request_mask and st_mask are:

XSTAT_MODE Want/got st_mode
XSTAT_NLINK Want/got st_nlink
XSTAT_UID Want/got st_uid
XSTAT_GID Want/got st_gid
XSTAT_RDEV Want/got st_rdev
XSTAT_ATIME Want/got st_atime
XSTAT_MTIME Want/got st_mtime
XSTAT_CTIME Want/got st_ctime
XSTAT_INO Want/got st_ino
XSTAT_SIZE Want/got st_size
XSTAT_BLOCKS Want/got st_blocks
XSTAT_BASIC_STATS [The stuff in the normal stat struct]
XSTAT_IOC_FLAGS Want/got FS_IOC_GETFLAGS
XSTAT_BTIME Want/got st_btime
XSTAT_GEN Want/got st_gen
XSTAT_VERSION Want/got st_data_version
XSTAT_VOLUME_ID Want/got st_volume_id
XSTAT_ALL_STATS [All currently available stuff]

The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra flags
that might be supplied by the filesystem. Note that Ext4 returns flags outside
of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS. Should
{EXT4,FS}_FL_USER_VISIBLE be extended to cover them? Or should the extra flags
be suppressed?

The defined bits in the st_information field give local system data on a file,
how it is accessed, where it is and what it does:

XSTAT_INFO_ENCRYPTED File is encrypted
XSTAT_INFO_TEMPORARY File is temporary (NTFS/CIFS/deleted)
XSTAT_INFO_FABRICATED File was made up by filesystem
XSTAT_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs)
XSTAT_INFO_REMOTE File is remote
XSTAT_INFO_OFFLINE File is offline (CIFS)
XSTAT_INFO_AUTOMOUNT Dir is automount trigger
XSTAT_INFO_AUTODIR Dir provides unlisted automounts
XSTAT_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details
XSTAT_INFO_HAS_ACL File has an ACL of some sort
XSTAT_INFO_REPARSE_POINT File is reparse point (NTFS/CIFS)
XSTAT_INFO_HIDDEN File is marked hidden (DOS+)
XSTAT_INFO_SYSTEM File is marked system (DOS+)
XSTAT_INFO_ARCHIVE File is marked archive (DOS+)

These are for the use of GUI tools that might want to mark files specially,
depending on what they are. I've tried not to provide overlap with
st_ioc_flags where something usable exists there. Should Hidden, System and
Archive flags be associated with ioc_flags, perhaps with ioc_flags extended to
64-bits?

The system calls are:

ssize_t ret = xstat(int dfd,
const char *filename,
unsigned int flags,
unsigned int mask,
struct xstat *buffer);

ssize_t ret = fxstat(unsigned fd,
unsigned int flags,
unsigned int mask,
struct xstat *buffer);

The dfd, filename, flags and fd parameters indicate the file to query. There
is no equivalent of lstat() as that can be emulated with xstat() by passing
AT_SYMLINK_NOFOLLOW in flags.

AT_FORCE_ATTR_SYNC can also be set in flags. This will require a network
filesystem to synchronise its attributes with the server.

mask is a bitmask indicating the fields in struct xstat that are of interest to
the caller. The user should set this to XSTAT__BASIC_STATS to get the
basic set returned by stat().

Should there just be one xstat() syscall that does fxstat() if filename is NULL?

The fields in struct xstat come in a number of classes:

(0) st_dev, st_blksize, st_information.

These are local data and are always available.

(1) st_mode, st_nlinks, st_uid, st_gid, st_[amc]time, st_ino, st_size,
st_blocks.

These will be returned whether the caller asks for them or not. The
corresponding bits in result_mask will be set to indicate their presence.

If the caller didn't ask for them, then they may be approximated. For
example, NFS won't waste any time updating them from the server, unless as
a byproduct of updating something requested.

If the values don't actually exist for the underlying object (such as UID
or GID on a DOS file), then the bit won't be set in the result_mask, even
if the caller asked for the value and the returned value will be a
fabrication.

(2) st_rdev.

As for class (1), but this won't be returned if the file is not a blockdev
or chardev. The bit will be cleared if the value is not returned.

(3) File creation time (st_btime), inode generation (st_gen), data version
(st_version), volume_id (st_volume_id) and inode flags (st_ioc_flags).

These will be returned if available whether the caller asked for them or
not. The corresponding bits in result_mask will be set or cleared as
appropriate to indicate their presence.

If the caller didn't ask for them, then they may be approximated. For
example, NFS won't waste any time updating them from the server, unless
as a byproduct of updating something requested.

At the moment, this will only work on x86_64 and i386 as it requires system
calls to be wired up.

=======
TESTING
=======

The following test program can be used to test the xstat system call:

/* Test the xstat() system call
*
* Copyright (C) 2010 Red Hat, Inc. All Rights Reserved.
* Written by David Howells ([email protected])
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public Licence
* as published by the Free Software Foundation; either version
* 2 of the Licence, or (at your option) any later version.
*/

#define _GNU_SOURCE
#define _ATFILE_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <time.h>
#include <sys/syscall.h>
#include <sys/stat.h>
#include <sys/types.h>

#define AT_NO_AUTOMOUNT 0x800
#define AT_FORCE_ATTR_SYNC 0x2000

#define XSTAT_MODE 0x00000001U
#define XSTAT_NLINK 0x00000002U
#define XSTAT_UID 0x00000004U
#define XSTAT_GID 0x00000008U
#define XSTAT_RDEV 0x00000010U
#define XSTAT_ATIME 0x00000020U
#define XSTAT_MTIME 0x00000040U
#define XSTAT_CTIME 0x00000080U
#define XSTAT_INO 0x00000100U
#define XSTAT_SIZE 0x00000200U
#define XSTAT_BLOCKS 0x00000400U
#define XSTAT_BASIC_STATS 0x000007ffU
#define XSTAT_BTIME 0x00000800U
#define XSTAT_GEN 0x00001000U
#define XSTAT_VERSION 0x00002000U
#define XSTAT_IOC_FLAGS 0x00004000U
#define XSTAT_VOLUME_ID 0x00008000U
#define XSTAT_ALL_STATS 0x0000ffffU

struct xstat_dev {
uint32_t major;
uint32_t minor;
};

struct xstat_time {
uint64_t tv_sec;
uint32_t tv_nsec;
uint32_t tv_granularity;
};

struct xstat {
uint32_t st_mask;
uint32_t st_mode;
uint32_t st_nlink;
uint32_t st_uid;
uint32_t st_gid;
uint32_t st_information;
uint32_t st_ioc_flags;
uint32_t st_blksize;
struct xstat_dev st_rdev;
struct xstat_dev st_dev;
struct xstat_time st_atim;
struct xstat_time st_btim;
struct xstat_time st_ctim;
struct xstat_time st_mtim;
uint64_t st_ino;
uint64_t st_size;
uint64_t st_blksize;
uint64_t st_blocks;
uint64_t st_gen;
uint64_t st_version;
uint64_t st_volume_id[16];
uint64_t st_spares[11];
};

#define XSTAT_INFO_ENCRYPTED 0x00000001U
#define XSTAT_INFO_TEMPORARY 0x00000002U
#define XSTAT_INFO_FABRICATED 0x00000004U
#define XSTAT_INFO_KERNEL_API 0x00000008U
#define XSTAT_INFO_REMOTE 0x00000010U
#define XSTAT_INFO_OFFLINE 0x00000020U
#define XSTAT_INFO_AUTOMOUNT 0x00000040U
#define XSTAT_INFO_AUTODIR 0x00000080U
#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U
#define XSTAT_INFO_HAS_ACL 0x00000200U
#define XSTAT_INFO_REPARSE_POINT 0x00000400U
#define XSTAT_INFO_HIDDEN 0x00000800U
#define XSTAT_INFO_SYSTEM 0x00001000U
#define XSTAT_INFO_ARCHIVE 0x00002000U

#define __NR_xstat 312
#define __NR_fxstat 313

static __attribute__((unused))
ssize_t xstat(int dfd, const char *filename, unsigned flags,
unsigned int mask, struct xstat *buffer)
{
return syscall(__NR_xstat, dfd, filename, flags, mask, buffer);
}

static __attribute__((unused))
ssize_t fxstat(int fd, unsigned flags,
unsigned int mask, struct xstat *buffer)
{
return syscall(__NR_fxstat, fd, flags, mask, buffer);
}

static void print_time(const char *field, const struct xstat_time *xstm)
{
struct tm tm;
time_t tim;
char buffer[100];
int len;

tim = xstm->tv_sec;
if (!localtime_r(&tim, &tm)) {
perror("localtime_r");
exit(1);
}
len = strftime(buffer, 100, "%F %T", &tm);
if (len == 0) {
perror("strftime");
exit(1);
}
printf("%s", field);
fwrite(buffer, 1, len, stdout);
printf(".%09u", xstm->tv_nsec);
len = strftime(buffer, 100, "%z", &tm);
if (len == 0) {
perror("strftime2");
exit(1);
}
fwrite(buffer, 1, len, stdout);
printf("\n");
}

static void dump_xstat(struct xstat *xst)
{
char buffer[256], ft;

printf("results=%x\n", xst->st_mask);

printf(" ");
if (xst->st_mask & XSTAT_SIZE)
printf(" Size: %-15llu", (unsigned long long) xst->st_size);
if (xst->st_mask & XSTAT_BLOCKS)
printf(" Blocks: %-10llu", (unsigned long long) xst->st_blocks);
printf(" IO Block: %-6llu ", (unsigned long long) xst->st_blksize);
if (xst->st_mask & XSTAT_MODE) {
switch (xst->st_mode & S_IFMT) {
case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break;
case S_IFCHR: printf(" character special file\n"); ft = 'c'; break;
case S_IFDIR: printf(" directory\n"); ft = 'd'; break;
case S_IFBLK: printf(" block special file\n"); ft = 'b'; break;
case S_IFREG: printf(" regular file\n"); ft = '-'; break;
case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break;
case S_IFSOCK: printf(" socket\n"); ft = 's'; break;
default:
printf("unknown type (%o)\n", xst->st_mode & S_IFMT);
ft = '?';
break;
}
}

sprintf(buffer, "%02x:%02x", xst->st_dev.major, xst->st_dev.minor);
printf("Device: %-15s", buffer);
if (xst->st_mask & XSTAT_INO)
printf(" Inode: %-11llu", (unsigned long long) xst->st_ino);
if (xst->st_mask & XSTAT_SIZE)
printf(" Links: %-5u", xst->st_nlink);
if (xst->st_mask & XSTAT_RDEV)
printf(" Device type: %u,%u",
xst->st_rdev.major, xst->st_rdev.minor);
printf("\n");

if (xst->st_mask & XSTAT_MODE)
printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ",
xst->st_mode & 07777,
ft,
xst->st_mode & S_IRUSR ? 'r' : '-',
xst->st_mode & S_IWUSR ? 'w' : '-',
xst->st_mode & S_IXUSR ? 'x' : '-',
xst->st_mode & S_IRGRP ? 'r' : '-',
xst->st_mode & S_IWGRP ? 'w' : '-',
xst->st_mode & S_IXGRP ? 'x' : '-',
xst->st_mode & S_IROTH ? 'r' : '-',
xst->st_mode & S_IWOTH ? 'w' : '-',
xst->st_mode & S_IXOTH ? 'x' : '-');
if (xst->st_mask & XSTAT_UID)
printf("Uid: %d \n", xst->st_uid);
if (xst->st_mask & XSTAT_GID)
printf("Gid: %u\n", xst->st_gid);

if (xst->st_mask & XSTAT_ATIME)
print_time("Access: ", &xst->st_atim);
if (xst->st_mask & XSTAT_MTIME)
print_time("Modify: ", &xst->st_mtim);
if (xst->st_mask & XSTAT_CTIME)
print_time("Change: ", &xst->st_ctim);
if (xst->st_mask & XSTAT_BTIME)
print_time("Create: ", &xst->st_btim);

if (xst->st_mask & XSTAT_GEN)
printf("Inode version: %llxh\n", (unsigned long long) xst->st_gen);
if (xst->st_mask & XSTAT_VERSION)
printf("Data version: %llxh\n", (unsigned long long) xst->st_version);

if (xst->st_mask & XSTAT_IOC_FLAGS) {
unsigned char bits;
int loop, byte;

static char flag_representation[32 + 1] =
/* FS_IOC_GETFLAGS flags: */
"????????" /* 31-24 0x00000000-ff000000 */
"????ehTD" /* 23-16 0x00000000-00ff0000 */
"tj?IE?XZ" /* 15- 8 0x00000000-0000ff00 */
"AdaiScus" /* 7- 0 0x00000000-000000ff */
;

printf("Inode flags: %08x (", xst->st_ioc_flags);
for (byte = 32 - 8; byte >= 0; byte -= 8) {
bits = xst->st_ioc_flags >> byte;
for (loop = 7; loop >= 0; loop--) {
int bit = byte + loop;

if (bits & 0x80)
putchar(flag_representation[31 - bit]);
else
putchar('-');
bits <<= 1;
}
if (byte)
putchar(' ');
}
printf(")\n");
}

if (xst->st_information) {
unsigned char bits;
int loop, byte;

static char info_representation[32 + 1] =
/* XSTAT_INFO_ flags: */
"????????" /* 31-24 0x00000000-ff000000 */
"????????" /* 23-16 0x00000000-00ff0000 */
"??ASHRan" /* 15- 8 0x00000000-0000ff00 */
"dmorkfte" /* 7- 0 0x00000000-000000ff */
;

printf("Information: %08x (", xst->st_information);
for (byte = 32 - 8; byte >= 0; byte -= 8) {
bits = xst->st_information >> byte;
for (loop = 7; loop >= 0; loop--) {
int bit = byte + loop;

if (bits & 0x80)
putchar(info_representation[31 - bit]);
else
putchar('-');
bits <<= 1;
}
if (byte)
putchar(' ');
}
printf(")\n");
}

if (xst->st_mask & XSTAT_VOLUME_ID) {
int loop;
printf("Volume ID: ");
for (loop = 0; loop < sizeof(xst->st_volume_id); loop++) {
printf("%02x", xst->st_volume_id[loop]);
if (loop == 7)
printf("-");
}
printf("\n");
}
}

void dump_hex(unsigned long long *data, int from, int to)
{
unsigned offset, print_offset = 1, col = 0;

from /= 8;
to = (to + 7) / 8;

for (offset = from; offset < to; offset++) {
if (print_offset) {
printf("%04x: ", offset * 8);
print_offset = 0;
}
printf("%016llx", data[offset]);
col++;
if ((col & 3) == 0) {
printf("\n");
print_offset = 1;
} else {
printf(" ");
}
}

if (!print_offset)
printf("\n");
}

int main(int argc, char **argv)
{
struct xstat xst;
int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW;

unsigned int mask = XSTAT_ALL_STATS;

for (argv++; *argv; argv++) {
if (strcmp(*argv, "-F") == 0) {
atflag |= AT_FORCE_ATTR_SYNC;
continue;
}
if (strcmp(*argv, "-L") == 0) {
atflag &= ~AT_SYMLINK_NOFOLLOW;
continue;
}
if (strcmp(*argv, "-O") == 0) {
mask &= ~XSTAT_BASIC_STATS;
continue;
}
if (strcmp(*argv, "-A") == 0) {
atflag |= AT_NO_AUTOMOUNT;
continue;
}
if (strcmp(*argv, "-R") == 0) {
raw = 1;
continue;
}

memset(&xst, 0xbf, sizeof(xst));
ret = xstat(AT_FDCWD, *argv, atflag, mask, &xst);
printf("xstat(%s) = %d\n", *argv, ret);
if (ret < 0) {
perror(*argv);
exit(1);
}

if (raw)
dump_hex((unsigned long long *)&xst, 0, sizeof(xst));

dump_xstat(&xst);
}
return 0;
}

Just compile and run, passing it paths to the files you want to examine:

[root@andromeda ~]# /tmp/xstat /proc/$$
xstat(/proc/2074) = 160
results=47ef
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 00:03 Inode: 9072 Links: 7
Access: (0555/dr-xr-xr-x) Uid: 0
Gid: 0
Access: 2010-07-14 16:50:46.609336272+0100
Modify: 2010-07-14 16:50:46.609336272+0100
Change: 2010-07-14 16:50:46.609336272+0100
Inode flags: 0000000100000000 (-------- -------- -------- -------S -------- -------- -------- --------)
[root@andromeda ~]# /tmp/xstat /afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm
xstat(/afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm) = 160
results=77ef
Size: 5413882 Blocks: 0 IO Block: 4096 regular file
Device: 00:15 Inode: 2288 Links: 1
Access: (0644/-rw-r--r--) Uid: 75338
Gid: 0
Access: 2008-11-05 19:47:22.000000000+0000
Modify: 2008-11-05 19:47:22.000000000+0000
Change: 2008-11-05 19:47:22.000000000+0000
Inode version: 795h
Data version: 2h
Inode flags: 0000000800000000 (-------- -------- -------- ----r--- -------- -------- -------- --------)

Signed-off-by: David Howells <[email protected]>
---

arch/x86/syscalls/syscall_32.tbl | 2
arch/x86/syscalls/syscall_64.tbl | 2
fs/stat.c | 350 +++++++++++++++++++++++++++++++++++---
include/linux/fcntl.h | 1
include/linux/fs.h | 4
include/linux/stat.h | 126 +++++++++++++-
include/linux/syscalls.h | 7 +
7 files changed, 461 insertions(+), 31 deletions(-)

diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index 29f9f05..980eb5a 100644
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@ -355,3 +355,5 @@
346 i386 setns sys_setns
347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv
348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev
+349 i386 xstat sys_xstat
+350 i386 fxstat sys_fxstat
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index dd29a9e..7ae24bb 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -318,6 +318,8 @@
309 common getcpu sys_getcpu
310 64 process_vm_readv sys_process_vm_readv
311 64 process_vm_writev sys_process_vm_writev
+312 common xstat sys_xstat
+313 common fxstat sys_fxstat
#
# x32-specific system call numbers start at 512 to avoid cache impact
# for native 64-bit operation.
diff --git a/fs/stat.c b/fs/stat.c
index c733dc5..af3ef33 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -18,8 +18,20 @@
#include <asm/uaccess.h>
#include <asm/unistd.h>

+/**
+ * generic_fillattr - Fill in the basic attributes from the inode struct
+ * @inode: Inode to use as the source
+ * @stat: Where to fill in the attributes
+ *
+ * Fill in the basic attributes in the kstat structure from data that's to be
+ * found on the VFS inode structure. This is the default if no getattr inode
+ * operation is supplied.
+ */
void generic_fillattr(struct inode *inode, struct kstat *stat)
{
+ struct super_block *sb = inode->i_sb;
+ u32 x;
+
stat->dev = inode->i_sb->s_dev;
stat->ino = inode->i_ino;
stat->mode = inode->i_mode;
@@ -27,17 +39,61 @@ void generic_fillattr(struct inode *inode, struct kstat *stat)
stat->uid = inode->i_uid;
stat->gid = inode->i_gid;
stat->rdev = inode->i_rdev;
- stat->size = i_size_read(inode);
- stat->atime = inode->i_atime;
stat->mtime = inode->i_mtime;
stat->ctime = inode->i_ctime;
- stat->blksize = (1 << inode->i_blkbits);
+ stat->size = i_size_read(inode);
stat->blocks = inode->i_blocks;
-}
+ stat->blksize = (1 << inode->i_blkbits);

+ stat->result_mask |= XSTAT_BASIC_STATS & ~XSTAT_RDEV;
+ if (IS_NOATIME(inode))
+ stat->result_mask &= ~XSTAT_ATIME;
+ else
+ stat->atime = inode->i_atime;
+
+ if (S_ISREG(stat->mode) && stat->nlink == 0)
+ stat->information |= XSTAT_INFO_TEMPORARY;
+ if (IS_AUTOMOUNT(inode))
+ stat->information |= XSTAT_INFO_AUTOMOUNT;
+ if (IS_POSIXACL(inode))
+ stat->information |= XSTAT_INFO_HAS_ACL;
+
+ /* if unset, assume 1s granularity */
+ stat->tv_granularity = sb->s_time_gran ?: 1000000000U;
+
+ if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode)))
+ stat->result_mask |= XSTAT_RDEV;
+
+ x = ((u32*)&stat->volume_id)[0] = ((u32*)&sb->s_volume_id)[0];
+ x |= ((u32*)&stat->volume_id)[1] = ((u32*)&sb->s_volume_id)[1];
+ x |= ((u32*)&stat->volume_id)[2] = ((u32*)&sb->s_volume_id)[2];
+ x |= ((u32*)&stat->volume_id)[3] = ((u32*)&sb->s_volume_id)[3];
+ if (x)
+ stat->result_mask |= XSTAT_VOLUME_ID;
+}
EXPORT_SYMBOL(generic_fillattr);

-int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
+/**
+ * vfs_xgetattr - Get the basic and extra attributes of a file
+ * @mnt: The mountpoint to which the dentry belongs
+ * @dentry: The file of interest
+ * @stat: Where to return the statistics
+ *
+ * Ask the filesystem for a file's attributes. The caller must have preset
+ * stat->request_mask and stat->query_flags to indicate what they want.
+ *
+ * If the file is remote, the filesystem can be forced to update the attributes
+ * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags.
+ *
+ * Bits must have been set in stat->request_mask to indicate which attributes
+ * the caller wants retrieving. Any such attribute not requested may be
+ * returned anyway, but the value may be approximate, and, if remote, may not
+ * have been synchronised with the server.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat)
{
struct inode *inode = dentry->d_inode;
int retval;
@@ -46,64 +102,184 @@ int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
if (retval)
return retval;

+ stat->result_mask = 0;
+ stat->information = 0;
+ stat->ioc_flags = 0;
if (inode->i_op->getattr)
return inode->i_op->getattr(mnt, dentry, stat);

generic_fillattr(inode, stat);
return 0;
}
+EXPORT_SYMBOL(vfs_xgetattr);

+/**
+ * vfs_getattr - Get the basic attributes of a file
+ * @mnt: The mountpoint to which the dentry belongs
+ * @dentry: The file of interest
+ * @stat: Where to return the statistics
+ *
+ * Ask the filesystem for a file's attributes. If remote, the filesystem isn't
+ * forced to update its files from the backing store. Only the basic set of
+ * attributes will be retrieved; anyone wanting more must use vfs_getxattr(),
+ * as must anyone who wants to force attributes to be sync'd with the server.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
+{
+ stat->query_flags = 0;
+ stat->request_mask = XSTAT_BASIC_STATS;
+ return vfs_xgetattr(mnt, dentry, stat);
+}
EXPORT_SYMBOL(vfs_getattr);

-int vfs_fstat(unsigned int fd, struct kstat *stat)
+/**
+ * vfs_fxstat - Get basic and extra attributes by file descriptor
+ * @fd: The file descriptor refering to the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xgetattr(). The main difference is
+ * that it uses a file descriptor to determine the file location.
+ *
+ * The caller must have preset stat->query_flags and stat->request_mask as for
+ * vfs_xgetattr().
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_fxstat(unsigned int fd, struct kstat *stat)
{
struct file *f = fget(fd);
int error = -EBADF;

+ if (stat->query_flags & ~KSTAT_QUERY_FLAGS)
+ return -EINVAL;
if (f) {
- error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat);
+ error = vfs_xgetattr(f->f_path.mnt, f->f_path.dentry, stat);
fput(f);
}
return error;
}
+EXPORT_SYMBOL(vfs_fxstat);
+
+/**
+ * vfs_fstat - Get basic attributes by file descriptor
+ * @fd: The file descriptor refering to the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_getattr(). The main difference is
+ * that it uses a file descriptor to determine the file location.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_fstat(unsigned int fd, struct kstat *stat)
+{
+ stat->query_flags = 0;
+ stat->request_mask = XSTAT_BASIC_STATS;
+ return vfs_fxstat(fd, stat);
+}
EXPORT_SYMBOL(vfs_fstat);

-int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
- int flag)
+/**
+ * vfs_xstat - Get basic and extra attributes by filename
+ * @dfd: A file descriptor representing the base dir for a relative filename
+ * @filename: The name of the file of interest
+ * @flags: Flags to control the query
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xgetattr(). The main difference is
+ * that it uses a filename and base directory to determine the file location.
+ * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a
+ * symlink at the given name from being referenced.
+ *
+ * The caller must have preset stat->request_mask as for vfs_xgetattr(). The
+ * flags are also used to load up stat->query_flags.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_xstat(int dfd, const char __user *filename, int flags,
+ struct kstat *stat)
{
struct path path;
- int error = -EINVAL;
- int lookup_flags = 0;
+ int error, lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;

- if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
- AT_EMPTY_PATH)) != 0)
- goto out;
+ if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
+ AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
+ return -EINVAL;

- if (!(flag & AT_SYMLINK_NOFOLLOW))
- lookup_flags |= LOOKUP_FOLLOW;
- if (flag & AT_EMPTY_PATH)
+ if (flags & AT_SYMLINK_NOFOLLOW)
+ lookup_flags &= ~LOOKUP_FOLLOW;
+ if (flags & AT_NO_AUTOMOUNT)
+ lookup_flags &= ~LOOKUP_AUTOMOUNT;
+ if (flags & AT_EMPTY_PATH)
lookup_flags |= LOOKUP_EMPTY;

+ stat->query_flags = flags & KSTAT_QUERY_FLAGS;
error = user_path_at(dfd, filename, lookup_flags, &path);
- if (error)
- goto out;
-
- error = vfs_getattr(path.mnt, path.dentry, stat);
- path_put(&path);
-out:
+ if (!error) {
+ error = vfs_xgetattr(path.mnt, path.dentry, stat);
+ path_put(&path);
+ }
return error;
}
+EXPORT_SYMBOL(vfs_xstat);
+
+/**
+ * vfs_fstatat - Get basic attributes by filename
+ * @dfd: A file descriptor representing the base dir for a relative filename
+ * @filename: The name of the file of interest
+ * @flags: Flags to control the query
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xstat(). The difference is that it
+ * preselects basic stats only. The flags are used to load up
+ * stat->query_flags in addition to indicating symlink handling during path
+ * resolution.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
+ int flags)
+{
+ stat->request_mask = XSTAT_BASIC_STATS;
+ return vfs_xstat(dfd, filename, flags, stat);
+}
EXPORT_SYMBOL(vfs_fstatat);

-int vfs_stat(const char __user *name, struct kstat *stat)
+/**
+ * vfs_stat - Get basic attributes by filename
+ * @filename: The name of the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xstat(). The difference is that it
+ * preselects basic stats only, terminal symlinks are followed regardless and a
+ * remote filesystem can't be forced to query the server. If such is desired,
+ * vfs_xstat() should be used instead.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
+int vfs_stat(const char __user *filename, struct kstat *stat)
{
- return vfs_fstatat(AT_FDCWD, name, stat, 0);
+ stat->request_mask = XSTAT_BASIC_STATS;
+ return vfs_xstat(AT_FDCWD, filename, 0, stat);
}
EXPORT_SYMBOL(vfs_stat);

+/**
+ * vfs_stat - Get basic attributes by filename, without following terminal symlink
+ * @filename: The name of the file of interest
+ * @stat: The result structure to fill in.
+ *
+ * This function is a wrapper around vfs_xstat(). The difference is that it
+ * preselects basic stats only, terminal symlinks are note followed regardless
+ * and a remote filesystem can't be forced to query the server. If such is
+ * desired, vfs_xstat() should be used instead.
+ *
+ * 0 will be returned on success, and a -ve error code if unsuccessful.
+ */
int vfs_lstat(const char __user *name, struct kstat *stat)
{
- return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW);
+ return vfs_xstat(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat);
}
EXPORT_SYMBOL(vfs_lstat);

@@ -118,7 +294,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
{
static int warncount = 5;
struct __old_kernel_stat tmp;
-
+
if (warncount > 0) {
warncount--;
printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n",
@@ -143,7 +319,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta
#if BITS_PER_LONG == 32
if (stat->size > MAX_NON_LFS)
return -EOVERFLOW;
-#endif
+#endif
tmp.st_size = stat->size;
tmp.st_atime = stat->atime.tv_sec;
tmp.st_mtime = stat->mtime.tv_sec;
@@ -225,7 +401,7 @@ static int cp_new_stat(struct kstat *stat, struct stat __user *statbuf)
#if BITS_PER_LONG == 32
if (stat->size > MAX_NON_LFS)
return -EOVERFLOW;
-#endif
+#endif
tmp.st_size = stat->size;
tmp.st_atime = stat->atime.tv_sec;
tmp.st_mtime = stat->mtime.tv_sec;
@@ -412,6 +588,122 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
}
#endif /* __ARCH_WANT_STAT64 */

+/*
+ * Get the xstat parameters if supplied
+ */
+static int xstat_get_params(unsigned int mask, struct xstat __user *buffer,
+ struct kstat *stat)
+{
+ memset(stat, 0xde, sizeof(*stat)); // DEBUGGING
+
+ if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer)))
+ return -EFAULT;
+
+ stat->request_mask = mask & XSTAT_ALL_STATS;
+ stat->result_mask = 0;
+ return 0;
+}
+
+/*
+ * Set the xstat results.
+ *
+ * If the buffer size was 0, we just return the size of the buffer needed to
+ * return the full result.
+ *
+ * If bufsize indicates a buffer of insufficient size to hold the full result,
+ * we return -E2BIG.
+ *
+ * Otherwise we copy the extended stats to userspace and return the amount of
+ * data written into the buffer (or -EFAULT).
+ */
+static long xstat_set_result(struct kstat *stat, struct xstat __user *buffer)
+{
+ u32 mask = stat->result_mask, gran = stat->tv_granularity;
+
+#define __put_timestamp(kts, uts) ( \
+ __put_user(kts.tv_sec, uts.tv_sec ) || \
+ __put_user(kts.tv_nsec, uts.tv_nsec ) || \
+ __put_user(gran, uts.tv_granularity ))
+
+ /* clear out anything we're not returning */
+ if (!(mask & XSTAT_IOC_FLAGS))
+ stat->ioc_flags = 0;
+ if (!(mask & XSTAT_BTIME))
+ memset(&stat->btime, 0, sizeof(stat->btime));
+ if (!(mask & XSTAT_GEN))
+ stat->gen = 0;
+ if (!(mask & XSTAT_VERSION))
+ stat->version = 0;
+ if (!(mask & XSTAT_VOLUME_ID))
+ memset(&stat->volume_id, 0, sizeof(stat->volume_id));
+
+ /* transfer the results */
+ if (__put_user(mask, &buffer->st_mask ) ||
+ __put_user(stat->mode, &buffer->st_mode ) ||
+ __put_user(stat->nlink, &buffer->st_nlink ) ||
+ __put_user(stat->uid, &buffer->st_uid ) ||
+ __put_user(stat->gid, &buffer->st_gid ) ||
+ __put_user(stat->information, &buffer->st_information ) ||
+ __put_user(stat->ioc_flags, &buffer->st_ioc_flags ) ||
+ __put_user(stat->blksize, &buffer->st_blksize ) ||
+ __put_user(MAJOR(stat->rdev), &buffer->st_rdev.major ) ||
+ __put_user(MINOR(stat->rdev), &buffer->st_rdev.minor ) ||
+ __put_user(MAJOR(stat->dev), &buffer->st_dev.major ) ||
+ __put_user(MINOR(stat->dev), &buffer->st_dev.minor ) ||
+ __put_timestamp(stat->atime, &buffer->st_atime ) ||
+ __put_timestamp(stat->btime, &buffer->st_btime ) ||
+ __put_timestamp(stat->ctime, &buffer->st_ctime ) ||
+ __put_timestamp(stat->mtime, &buffer->st_mtime ) ||
+ __put_user(stat->ino, &buffer->st_ino ) ||
+ __put_user(stat->size, &buffer->st_size ) ||
+ __put_user(stat->blocks, &buffer->st_blocks ) ||
+ __put_user(stat->gen, &buffer->st_gen ) ||
+ __put_user(stat->version, &buffer->st_version ) ||
+ __copy_to_user(&buffer->st_volume_id, &stat->volume_id,
+ sizeof(buffer->st_volume_id) ) ||
+ __clear_user(&buffer->__spares, sizeof(buffer->__spares)))
+ return -EFAULT;
+ return 0;
+}
+
+/*
+ * System call to get extended stats by path
+ */
+SYSCALL_DEFINE5(xstat,
+ int, dfd, const char __user *, filename, unsigned, flags,
+ unsigned int, mask, struct xstat __user *, buffer)
+{
+ struct kstat stat;
+ int error;
+
+ error = xstat_get_params(mask, buffer, &stat);
+ if (error != 0)
+ return error;
+ error = vfs_xstat(dfd, filename, flags, &stat);
+ if (error)
+ return error;
+ return xstat_set_result(&stat, buffer);
+}
+
+/*
+ * System call to get extended stats by file descriptor
+ */
+SYSCALL_DEFINE4(fxstat, unsigned int, fd, unsigned int, flags,
+ unsigned int, mask, struct xstat __user *, buffer)
+{
+ struct kstat stat;
+ int error;
+
+ error = xstat_get_params(mask, buffer, &stat);
+ if (error < 0)
+ return error;
+ stat.query_flags = flags;
+ error = vfs_fxstat(fd, &stat);
+ if (error)
+ return error;
+ return xstat_set_result(&stat, buffer);
+}
+
/* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
void __inode_add_bytes(struct inode *inode, loff_t bytes)
{
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index f550f89..faa9e5d 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
@@ -47,6 +47,7 @@
#define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */
#define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */
#define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */
+#define AT_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */

#ifdef __KERNEL__

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8de6755..ec6c62e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1467,6 +1467,7 @@ struct super_block {

char s_id[32]; /* Informational name */
u8 s_uuid[16]; /* UUID */
+ unsigned char s_volume_id[16]; /* Volume identifier */

void *s_fs_info; /* Filesystem private info */
unsigned int s_max_links;
@@ -2470,6 +2471,7 @@ extern const struct inode_operations page_symlink_inode_operations;
extern int generic_readlink(struct dentry *, char __user *, int);
extern void generic_fillattr(struct inode *, struct kstat *);
extern int vfs_getattr(struct vfsmount *, struct dentry *, struct kstat *);
+extern int vfs_xgetattr(struct vfsmount *, struct dentry *, struct kstat *);
void __inode_add_bytes(struct inode *inode, loff_t bytes);
void inode_add_bytes(struct inode *inode, loff_t bytes);
void inode_sub_bytes(struct inode *inode, loff_t bytes);
@@ -2482,6 +2484,8 @@ extern int vfs_stat(const char __user *, struct kstat *);
extern int vfs_lstat(const char __user *, struct kstat *);
extern int vfs_fstat(unsigned int, struct kstat *);
extern int vfs_fstatat(int , const char __user *, struct kstat *, int);
+extern int vfs_xstat(int, const char __user *, int, struct kstat *);
+extern int vfs_xfstat(unsigned int, struct kstat *);

extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
unsigned long arg);
diff --git a/include/linux/stat.h b/include/linux/stat.h
index 611c398..0ff561a 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -3,6 +3,7 @@

#ifdef __KERNEL__

+#include <linux/types.h>
#include <asm/stat.h>

#endif
@@ -46,6 +47,117 @@

#endif

+/*
+ * Query request/result mask
+ *
+ * Bits should be set in request_mask to request particular items when calling
+ * xstat() or fxstat().
+ *
+ * The bits in st_mask may or may not be set upon return, in part depending on
+ * what was set in the mask argument:
+ *
+ * - if not available at all, the bit will be cleared before returning and the
+ * field will be cleared; otherwise,
+ *
+ * - if AT_FORCE_ATTR_SYNC is set, then the datum will be synchronised to the
+ * server and the field and bit will be set on return; otherwise,
+ *
+ * - if explicitly requested, the datum will be synchronised to a server or
+ * other medium if out of date before being returned, and the bit will be set
+ * on return; otherwise,
+ *
+ * - if not requested, but available in approximate form without any effort, it
+ * will be filled in anyway, and the bit will be set upon return (it might
+ * not be up to date, however, and no attempt will be made to synchronise the
+ * internal state first); otherwise,
+ *
+ * - the field and the bit will be cleared before returning.
+ *
+ * Items in XSTAT_BASIC_STATS may be marked unavailable on return, but they
+ * will have a value installed for compatibility purposes so that stat() and
+ * co. can be emulated in userspace.
+ */
+#define XSTAT_MODE 0x00000001U /* want/got st_mode */
+#define XSTAT_NLINK 0x00000002U /* want/got st_nlink */
+#define XSTAT_UID 0x00000004U /* want/got st_uid */
+#define XSTAT_GID 0x00000008U /* want/got st_gid */
+#define XSTAT_RDEV 0x00000010U /* want/got st_rdev */
+#define XSTAT_ATIME 0x00000020U /* want/got st_atime */
+#define XSTAT_MTIME 0x00000040U /* want/got st_mtime */
+#define XSTAT_CTIME 0x00000080U /* want/got st_ctime */
+#define XSTAT_INO 0x00000100U /* want/got st_ino */
+#define XSTAT_SIZE 0x00000200U /* want/got st_size */
+#define XSTAT_BLOCKS 0x00000400U /* want/got st_blocks */
+#define XSTAT_BASIC_STATS 0x000007ffU /* the stuff in the normal stat struct */
+#define XSTAT_IOC_FLAGS 0x00000800U /* want/got FS_IOC_GETFLAGS */
+#define XSTAT_BTIME 0x00001000U /* want/got st_btime */
+#define XSTAT_GEN 0x00002000U /* want/got st_gen */
+#define XSTAT_VERSION 0x00004000U /* want/got st_version */
+#define XSTAT_VOLUME_ID 0x00008000U /* want/got st_volume_id */
+#define XSTAT_ALL_STATS 0x0000ffffU /* all supported stats */
+
+/*
+ * Extended stat structures
+ */
+struct xstat_dev {
+ uint32_t major, minor;
+};
+
+struct xstat_time {
+ int64_t tv_sec;
+ uint32_t tv_nsec;
+ uint32_t tv_granularity; /* time granularity (in nS) */
+};
+
+struct xstat {
+ uint32_t st_mask; /* what results were written */
+ uint32_t st_mode; /* file mode */
+ uint32_t st_nlink; /* number of hard links */
+ uint32_t st_uid; /* user ID of owner */
+ uint32_t st_gid; /* group ID of owner */
+ uint32_t st_information; /* information about the file */
+ uint32_t st_ioc_flags; /* as FS_IOC_GETFLAGS */
+ uint32_t st_blksize; /* optimal size for filesystem I/O */
+ struct xstat_dev st_rdev; /* device ID of special file */
+ struct xstat_dev st_dev; /* ID of device containing file */
+ struct xstat_time st_atime; /* last access time */
+ struct xstat_time st_btime; /* file creation time */
+ struct xstat_time st_ctime; /* last attribute change time */
+ struct xstat_time st_mtime; /* last data modification time */
+ uint64_t st_ino; /* inode number */
+ uint64_t st_size; /* file size */
+ uint64_t st_blocks; /* number of 512-byte blocks allocated */
+ uint64_t st_gen; /* inode generation number */
+ uint64_t st_version; /* data version number */
+ uint8_t st_volume_id[16]; /* volume identifier */
+ uint64_t __spares[11]; /* spare space for future expansion */
+};
+
+/*
+ * Flags to be found in st_information
+ *
+ * These give information about the features or the state of a file that might
+ * be of use to ordinary userspace programs such as GUIs or ls rather than
+ * specialised tools.
+ *
+ * Additional information may be found in st_ioc_flags and we try not to
+ * overlap with it.
+ */
+#define XSTAT_INFO_ENCRYPTED 0x00000001U /* File is encrypted */
+#define XSTAT_INFO_TEMPORARY 0x00000002U /* File is temporary (NTFS/CIFS) */
+#define XSTAT_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */
+#define XSTAT_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */
+#define XSTAT_INFO_REMOTE 0x00000010U /* File is remote */
+#define XSTAT_INFO_OFFLINE 0x00000020U /* File is offline (CIFS) */
+#define XSTAT_INFO_AUTOMOUNT 0x00000040U /* Dir is automount trigger */
+#define XSTAT_INFO_AUTODIR 0x00000080U /* Dir provides unlisted automounts */
+#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U /* File has non-system ownership details */
+#define XSTAT_INFO_HAS_ACL 0x00000200U /* File has an ACL of some sort */
+#define XSTAT_INFO_REPARSE_POINT 0x00000400U /* File is reparse point (NTFS/CIFS) */
+#define XSTAT_INFO_HIDDEN 0x00000800U /* File is marked hidden (DOS+) */
+#define XSTAT_INFO_SYSTEM 0x00001000U /* File is marked system (DOS+) */
+#define XSTAT_INFO_ARCHIVE 0x00002000U /* File is marked archive (DOS+) */
+
#ifdef __KERNEL__
#define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO)
#define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO)
@@ -60,6 +172,12 @@
#include <linux/time.h>

struct kstat {
+ u32 query_flags; /* operational flags */
+#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC)
+ u32 request_mask; /* what fields the user asked for */
+ u32 result_mask; /* what fields the user got */
+ u32 information;
+ u32 ioc_flags; /* inode flags (FS_IOC_GETFLAGS) */
u64 ino;
dev_t dev;
umode_t mode;
@@ -67,14 +185,18 @@ struct kstat {
uid_t uid;
gid_t gid;
dev_t rdev;
+ unsigned int tv_granularity; /* granularity of times (in nS) */
loff_t size;
- struct timespec atime;
+ struct timespec atime;
struct timespec mtime;
struct timespec ctime;
+ struct timespec btime; /* file creation time */
unsigned long blksize;
unsigned long long blocks;
+ u64 gen; /* inode generation */
+ u64 version; /* data version */
+ unsigned char volume_id[16]; /* volume identifier */
};

#endif
-
#endif
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 3de3acb..ff9f8d9 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -45,6 +45,8 @@ struct shmid_ds;
struct sockaddr;
struct stat;
struct stat64;
+struct xstat_parameters;
+struct xstat;
struct statfs;
struct statfs64;
struct __sysctl_args;
@@ -858,4 +860,9 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
unsigned long riovcnt,
unsigned long flags);

+asmlinkage long sys_xstat(int dfd, const char __user *path, unsigned flags,
+ unsigned mask, struct xstat __user *buffer);
+asmlinkage long sys_fxstat(unsigned fd, unsigned flags,
+ unsigned mask, struct xstat __user *buffer);
+
#endif

2012-04-26 14:27:14

[permalink] [raw]

Subject: Re: [PATCH 4/6] xstat: NFS: Return extended attributes

Myklebust, Trond <[email protected]> wrote:

> Hmm... As far as I can see you are still doing an nfs_revalidate_inode()
> in the non-forced case. That will cause expired attributes to be
> retrieved from the server.

Revalidation is only done when you force it or explicitly ask for a basic stat
or the data version number:

- if (need_atime)
- err = __nfs_revalidate_inode(NFS_SERVER(inode), inode);
- else
- err = nfs_revalidate_inode(NFS_SERVER(inode), inode);
- if (!err) {
- generic_fillattr(inode, stat);
- stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
+ if (force || stat->request_mask & (XSTAT_BASIC_STATS | XSTAT_VERSION)) {
+ if (force || need_atime)
+ err = __nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ else
+ err = nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ if (err)
+ goto out;

Unfortunately, I think I have to revalidate if any of XSTAT_BASIC_STATS are
requested to maintain compatibility with stat() so that stat() can be done
with xstat(). On the other hand, stat() could be done by userspace with
xstat() and AT_FORCE_ATTR_SYNC, I suppose.

David

2012-04-19 23:33:02

[permalink] [raw]

Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On 2012-04-19, at 8:06 AM, David Howells wrote:
> Add a pair of system calls to make extended file stats available,
> including file creation time, inode version and data version where available through the underlying filesystem.
>
> The idea was initially proposed as a set of xattrs that could be
> retrieved with getxattr(), but the general preferance proved to be
> for new syscalls with an extended stat structure.

I would comment that it was the opposite. It was originally a
stat()-like extension that degraded into a messy getxattr() mess.

> (2) Lightweight stat: Ask for just those details of interest, and
> allow a netfs (such as NFS) to approximate anything not of
> interest, possibly without going to the server [Trond Myklebust,
> Ulrich Drepper].

This was my original motivation for this functionality, so you can
put my name here also.

> The fields in struct xstat come in a number of classes:
>
> (0) st_dev, st_blksize, st_information.
>
> These are local data and are always available.

For the extra two bits it would cost us, I don't think st_blksize
and st_information should always be returned. st_blksize may be
variable for a distributed filesystem, and some of the fields in
st_information (offline) may not be free to access either.

Cheers, Andreas

2012-05-11 09:03:56

[permalink] [raw]

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

On 2012-05-10, at 11:10 AM, Roland McGrath wrote:
> POSIX specifies st_blksize thusly: "A file system-specific preferred
> I/O block size for this object. In some file system types, this may
> vary from file to file."
>
> Since there is only one available to POSIX applications, it should map
> to the one that's described as "preferred IO size for general usage".

Sure, but statxat() isn't a POSIX API.

While I agree with the idea that there should be enough information about the underlying layout for applications to be able to submit good IO, it doesn't help if we have a bunch of extra fields that have vague meanings.

They will get filled in by the filesystem in a haphazard way, and will not be used by application developers that don't understand what they mean.

Cheers, Andreas

2012-05-08 21:13:40

[permalink] [raw]

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

T24gVHVlLCAyMDEyLTA1LTA4IGF0IDIxOjE5ICswMTAwLCBEYXZpZCBIb3dlbGxzIHdyb3RlOg0K
PiBTaG91bGQgSSBzcGxpdCB0aGUgZmlsZS1zcGVjaWZpYyBpbmZvIGFuZCB0aGUgZnMtc3BlY2lm
aWMgaW5mbyBhbmQgbWFrZSB0aGUNCj4gc2Vjb25kIG9wdGlvbmFsPyAgV2hhdCBJJ20gdGhpbmtp
bmcgb2YgaXMgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4gDQo+IEhhdmUgYSBmaWxlIGluZm9ybWF0
aW9uIHN0cnVjdHVyZToNCj4gDQo+IHN0cnVjdCBzdGF0eCB7DQo+IAkvKiAweDAwICovDQo+IAl1
aW50MzJfdAlzdF9tYXNrOwkvKiBXaGF0IHJlc3VsdHMgd2VyZSB3cml0dGVuICovDQo+IAl1aW50
MzJfdAlzdF9pbmZvcm1hdGlvbjsJLyogSW5mb3JtYXRpb24gYWJvdXQgdGhlIGZpbGUgKi8NCj4g
CXVpbnQxNl90CXN0X21vZGU7CS8qIEZpbGUgbW9kZSAqLw0KPiAJdWludDE2X3QJX19zcGFyZTBb
M107DQo+IAkvKiAweDEwICovDQo+IAl1aW50MzJfdAlzdF91aWQ7CQkvKiBVc2VyIElEIG9mIG93
bmVyICovDQo+IAl1aW50MzJfdAlzdF9naWQ7CQkvKiBHcm91cCBJRCBvZiBvd25lciAqLw0KPiAJ
dWludDMyX3QJc3Rfbmxpbms7CS8qIE51bWJlciBvZiBoYXJkIGxpbmtzICovDQo+IAl1aW50MzJf
dAlzdF9ibGtzaXplOwkvKiBPcHRpbWFsIHNpemUgZm9yIGZpbGVzeXN0ZW0gSS9PICovDQo+IAkv
KiAweDIwICovDQo+IAlzdHJ1Y3Qgc3RhdHhfZGV2IHN0X3JkZXY7CS8qIERldmljZSBJRCBvZiBz
cGVjaWFsIGZpbGUgKi8NCj4gCXN0cnVjdCBzdGF0eF9kZXYgc3RfZGV2OwkvKiBJRCBvZiBkZXZp
Y2UgY29udGFpbmluZyBmaWxlICovDQo+IAkvKiAweDMwICovDQo+IAlpbnQzMl90CQlzdF9hdGlt
ZV9uczsJLyogTGFzdCBhY2Nlc3MgdGltZSAobnMgcGFydCkgKi8NCj4gCWludDMyX3QJCXN0X2J0
aW1lX25zOwkvKiBGaWxlIGNyZWF0aW9uIHRpbWUgKG5zIHBhcnQpICovDQo+IAlpbnQzMl90CQlz
dF9jdGltZV9uczsJLyogTGFzdCBhdHRyaWJ1dGUgY2hhbmdlIHRpbWUgKG5zIHBhcnQpICovDQo+
IAlpbnQzMl90CQlzdF9tdGltZV9uczsJLyogTGFzdCBkYXRhIG1vZGlmaWNhdGlvbiB0aW1lIChu
cyBwYXJ0KSAqLw0KPiAJLyogMHg0MCAqLw0KPiAJaW50NjRfdAkJc3RfYXRpbWU7CS8qIExhc3Qg
YWNjZXNzIHRpbWUgKi8NCj4gCWludDY0X3QJCXN0X2J0aW1lOwkvKiBGaWxlIGNyZWF0aW9uIHRp
bWUgKi8NCj4gCWludDY0X3QJCXN0X2N0aW1lOwkvKiBMYXN0IGF0dHJpYnV0ZSBjaGFuZ2UgdGlt
ZSAqLw0KPiAJaW50NjRfdAkJc3RfbXRpbWU7CS8qIExhc3QgZGF0YSBtb2RpZmljYXRpb24gdGlt
ZSAqLw0KPiAJLyogMHg2MCAqLw0KPiAJdWludDY0X3QJc3RfaW5vOwkJLyogSW5vZGUgbnVtYmVy
ICovDQo+IAl1aW50NjRfdAlzdF9zaXplOwkvKiBGaWxlIHNpemUgKi8NCg0KU2hvdWxkIHdlIGNv
bnNpZGVyIG1ha2luZyB0aGUgc3Rfc2l6ZSBhbmQgc3RfYmxvY2tzIDEyOC1iaXQgdmFsdWVzIHdo
aWxlDQp3ZSdyZSBhdCBpdD8gQWx0ZXJuYXRpdmVseSwgd2UgY291bGQgYWRkIGFuIHN0X2lvY19m
bGFnIGZvciBpdCBsYXRlci4uLg0KDQo+IAl1aW50NjRfdAlzdF9ibG9ja3M7CS8qIE51bWJlciBv
ZiA1MTItYnl0ZSBibG9ja3MgYWxsb2NhdGVkICovDQo+IAl1aW50NjRfdAlzdF9nZW47CQkvKiBJ
bm9kZSBnZW5lcmF0aW9uIG51bWJlciAqLw0KPiAJdWludDY0X3QJc3RfdmVyc2lvbjsJLyogRGF0
YSB2ZXJzaW9uIG51bWJlciAqLw0KPiAJdWludDY0X3QJc3RfaW9jX2ZsYWdzOwkvKiBBcyBGU19J
T0NfR0VURkxBR1MgKi8NCj4gCS8qIDB4OTAgKi8NCj4gCXVpbnQ2NF90CV9fc3BhcmUxWzEzXTsJ
LyogU3BhcmUgc3BhY2UgZm9yIGZ1dHVyZSBleHBhbnNpb24gKi8NCj4gCS8qIDB4MTAwICovDQo+
IH07DQo+IA0KPiBBbmQgYW4gZnMgaW5mb3JtYXRpb24gc3RydWN0dXJlIGZvciBsZXNzIGNvbW1v
bmx5IG5lZWRlZCBkYXRhOg0KPiANCj4gc3RydWN0IHN0YXR4X2ZzaW5mbyB7DQo+IAkvKiAweDAw
IC0gR2VuZXJhbCBpbmZvICovDQo+IAl1aW50MzJfdAlzdF9tYXNrOwkvKiBXaGF0IG9wdGlvbmFs
IGZpZWxkcyBhcmUgZmlsbGVkIGluICovDQo+IAl1aW50MzJfdAlzdF90eXBlOwkvKiBGaWxlc3lz
dGVtIHR5cGUgZnJvbSBsaW51eC9tYWdpYy5oICovDQo+IA0KPiAJLyogMHgwOCAtIGZpbGUgdGlt
ZXN0YW1wIGdyYW51bGFyaXR5IGluZm8gKi8NCj4gCXVpbnQxNl90CXN0X2F0aW1lX2dyYW5fbWFu
dGlzc2E7CS8qIGdyYW4oc2VjcykgPSBtYW50ICogMTBeZXhwICovDQo+IAl1aW50MTZfdAlzdF9i
dGltZV9ncmFuX21hbnRpc3NhOw0KPiAJdWludDE2X3QJc3RfY3RpbWVfZ3Jhbl9tYW50aXNzYTsN
Cj4gCXVpbnQxNl90CXN0X210aW1lX2dyYW5fbWFudGlzc2E7DQo+IAkvKiAweDEwICovDQo+IAlp
bnQ4X3QJCXN0X2F0aW1lX2dyYW5fZXhwb25lbnQ7DQo+IAlpbnQ4X3QJCXN0X2J0aW1lX2dyYW5f
ZXhwb25lbnQ7DQo+IAlpbnQ4X3QJCXN0X2N0aW1lX2dyYW5fZXhwb25lbnQ7DQo+IAlpbnQ4X3QJ
CXN0X210aW1lX2dyYW5fZXhwb25lbnQ7DQo+IA0KPiAJLyogMHgxNCAtIEkvTyBwYXJhbWV0ZXJz
ICovDQo+IAl1aW50MzJfdAlzdF9ibGtzaXplOwkgIC8qIEZpbGUgYmxvY2sgc2l6ZSAqLw0KPiAJ
dWludDMyX3QJc3RfYWxsb2NfYmxrc2l6ZTsgLyogQWxsb2NhdGlvbiBibG9jayBzaXplL2FsaWdu
bWVudCAqLw0KPiAJdWludDMyX3QJc3Rfc21hbGxfaW9fc2l6ZTsgLyogSU8gc2l6ZS9hbGlnbm1l
bnQgdGhhdCBhdm9pZHMgZnMvcGFnZSBjYWNoZSBSTVcgKi8NCj4gCXVpbnQzMl90CXN0X3ByZWZf
aW9fc2l6ZTsgIC8qIFByZWZlcnJlZCBJTyBzaXplIGZvciBnZW5lcmFsIHVzYWdlICovDQo+IAl1
aW50MzJfdAlzdF9sYXJnZV9pb19zaXplOyAvKiBJTyBzaXplL2FsaWdubWVudCBmb3IgaGlnaCBi
YW5kd2lkdGggc2VxdWVudGlhbCBJTyAqLw0KPiANCj4gCS8qIDB4MjggLSBSZXN0cmljdGlvbnMg
b24gc3RydWN0IHN0YXR4IGNvbnRlbnRzICovDQo+IAl1aW50NjRfdAlzdF9zdXBwb3J0ZWRfaW9j
X2ZsYWdzOyAvKiBGU19JT0NfR0VURkxBR1MgZmxhZ3Mgc3VwcG9ydGVkICAqLw0KPiANCj4gCS8q
IDB4MzAgLSBWb2x1bWUvZmlsZXN5c3RlbSBpbmZvcm1hdGlvbiAqLw0KPiAJdWludDY0X3QJc3Rf
ZnNpZDsJLyogU2hvcnQgNjQtYml0IEZpbGVzeXN0ZW0gSUQgKGFzIHN0YXRmcykgKi8NCj4gCXVp
bnQ2NF90CV9fc3BhcmUwWzNdOw0KPiAJLyogMHg1MCAqLw0KPiAJdWludDhfdAkJc3Rfdm9sdW1l
X2lkWzE2XTsgLyogVm9sdW1lL2ZzIGlkZW50aWZpZXIgKi8NCj4gCXVpbnQ4X3QJCXN0X3ZvbHVt
ZV91dWlkWzE2XTsgLyogVm9sdW1lL2ZzIFVVSUQgKi8NCj4gCS8qIDB4ODAgKi8NCj4gCXVpbnQ2
NF90CV9fc3BhcmUxWzhdOw0KPiAJLyogMHhjMCAqLw0KPiAJdWludDhfdAkJc3Rfdm9sdW1lX25h
bWVbNjRdOyAvKiBWb2x1bWUgbmFtZSAodXAgdG8gNjQgY2hhcnMpICovDQo+IAkvKiAweDEwMCAq
Lw0KPiAJdWludDhfdAkJc3RfZG9tYWluX25hbWVbMjU2XTsgLyogRG9tYWluL2NlbGwvd29ya2dy
b3VwIG5hbWUgKHVwIHRvIDI1NiBjaGFycykgKi8NCj4gCS8qIDB4MjAwICovDQo+IH07DQoNCklm
IHlvdSBhcmUgbWFraW5nIGEgc2VwYXJhdGUgZnNpbmZvIHN0cnVjdHVyZSwgdGhlbiBpdCB3b3Vs
ZCBiZSBuaWNlIHRvDQpoYXZlIGZsYWdzIHRvIGluZGljYXRlIHdoYXQga2luZCBvZiBhY2xzIHRo
ZSBmaWxlc3lzdGVtIHN1cHBvcnRzLCBhbmQgaWYNCml0IHN1cHBvcnRzIGZlYXR1cmVzIHN1Y2gg
YXMgeGF0dHJzLCBzdWJmaWxlcyBhbmQvb3Igc25hcHNob3RzLg0KDQoNCg0KLS0gDQpUcm9uZCBN
eWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15
a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=

2012-05-10 17:10:20

[permalink] [raw]

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

POSIX specifies st_blksize thusly: "A file system-specific preferred I/O
block size for this object. In some file system types, this may vary from
file to file."

Since there is only one available to POSIX applications, it should map to
the one that's described as "preferred IO size for general usage".

Thanks,
Roland

2012-05-09 00:24:25

[permalink] [raw]

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

On Tue, May 08, 2012 at 09:19:42PM +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 */
> uint64_t st_blocks; /* Number of 512-byte blocks allocated */
> uint64_t st_gen; /* Inode generation number */

I don't think we want to expose the inode generation numbers. It is
trivial to construct NFS file handles (usually just fsid, inode
number and generation) with that information and hence bypass
security checks to access files.

> 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 */

That's per file information, not per filesystem. XFS definitely
needs this IO information per-file....

>
> /* 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 */

And there's all the remaining information needed to construct file
NFS handles without root priviledges...

> /* 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 */
> };
>
> One could argue a bit over what goes in which, should we go for this. This
> may be better split between multiple syscalls though (with the race that that
> implies) and potentially merging with statfs.
>
>
> The statxat() syscall [n?e xstat] could then use the 6th parameter thusly:
>
> asmlinkage long sys_statxat(int dfd, const char __user *path, unsigned flags,
> unsigned mask, struct statx __user *buffer,
> struct statx_fsinfo __user *fsinfo);
>
>
> letting fsinfo be NULL to indicate a lack of interest. I'm not sure we want
> to do that, though.
>
>
> Also, do Dave Chinner's ideas for indicating five I/O parameters want to be
> 32-bit numbers? Larger? Smaller? Can they be log2?

Definitely 32 bit, IMO, as it's not uncommon to see optimal IO sizes
in the tens of megabytes on large, high bandwidth storage systems.
As for being log2 - that's just making it more complex to use and
making code ugly - we'd have to convert to log2 in kernel, then
convert back in every single application....

> Note also, that I've suggested that we represent the timestamp granularity
> information as a decimal float (which requires 3 bytes per timestamp) and that
> we provide separate granularities for each timestamp.
>
> David
>

--
Dave Chinner
[email protected]

2012-05-10 09:14:59

[permalink] [raw]

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

Dave Chinner <[email protected]> wrote:

> > Also, do Dave Chinner's ideas for indicating five I/O parameters want to be
> > 32-bit numbers? Larger? Smaller? Can they be log2?
>
> Definitely 32 bit, IMO, as it's not uncommon to see optimal IO sizes
> in the tens of megabytes on large, high bandwidth storage systems.
> As for being log2 - that's just making it more complex to use and
> making code ugly - we'd have to convert to log2 in kernel, then
> convert back in every single application....

ilog2() in the kernel uses the CPU's bit-scan instruction if it has one and
converting back is just a bitshift operator.

But let's go with 32-bit fields for the moment. I presume we aren't worried
about a driver that wants to do a 4GB transfer...

David

2012-05-09 01:09:53

[permalink] [raw]

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

On Wed, May 09, 2012 at 10:24:20AM +1000, Dave Chinner wrote:
> On Tue, May 08, 2012 at 09:19:42PM +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 */
> > uint64_t st_blocks; /* Number of 512-byte blocks allocated */
> > uint64_t st_gen; /* Inode generation number */
>
> I don't think we want to expose the inode generation numbers. It is
> trivial to construct NFS file handles (usually just fsid, inode
> number and generation) with that information and hence bypass
> security checks to access files.

I'm not convinced there's much value in trying to keep filehandles
secret.

If you're going to base your security on a secret, then it should be
hard to guess, easy to keep secret, and changeable in case it ever does
get out.

Filehandles are pretty easy to guess (even without help like this), they
usually go over the wire in cleartext, and they can't be changed.

--b.

>
> > 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 */
>
> That's per file information, not per filesystem. XFS definitely
> needs this IO information per-file....
>
> >
> > /* 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 */
>
> And there's all the remaining information needed to construct file
> NFS handles without root priviledges...
>
> > /* 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 */
> > };
> >
> > One could argue a bit over what goes in which, should we go for this. This
> > may be better split between multiple syscalls though (with the race that that
> > implies) and potentially merging with statfs.
> >
> >
> > The statxat() syscall [née xstat] could then use the 6th parameter thusly:
> >
> > asmlinkage long sys_statxat(int dfd, const char __user *path, unsigned flags,
> > unsigned mask, struct statx __user *buffer,
> > struct statx_fsinfo __user *fsinfo);
> >
> >
> > letting fsinfo be NULL to indicate a lack of interest. I'm not sure we want
> > to do that, though.
> >
> >
> > Also, do Dave Chinner's ideas for indicating five I/O parameters want to be
> > 32-bit numbers? Larger? Smaller? Can they be log2?
>
> Definitely 32 bit, IMO, as it's not uncommon to see optimal IO sizes
> in the tens of megabytes on large, high bandwidth storage systems.
> As for being log2 - that's just making it more complex to use and
> making code ugly - we'd have to convert to log2 in kernel, then
> convert back in every single application....
>
> > Note also, that I've suggested that we represent the timestamp granularity
> > information as a decimal float (which requires 3 bytes per timestamp) and that
> > we provide separate granularities for each timestamp.
> >
> > David
> >
>
> --
> Dave Chinner
> [email protected]

2012-05-09 11:55:32

by Bernd Schubert

[permalink] [raw]

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

On 05/09/2012 01:19 PM, Christoph Hellwig wrote:
> On Wed, May 09, 2012 at 10:21:14AM +0100, David Howells wrote:
>> Dave Chinner<[email protected]> wrote:
>>
>>> I don't think we want to expose the inode generation numbers. It is
>>> trivial to construct NFS file handles (usually just fsid, inode
>>> number and generation) with that information and hence bypass
>>> security checks to access files.
>>
>> I was asked for it by Bernd Schubert for userspace NFS servers and FUSE -
>> maybe he can say what he wants it for.
>
> It's entirely broken, as a generation number might be part of the file
> handle (and for Linux-like filesystems normally is), but it's entirely
> up to the filesystem to decide how it works. That's why we added system
> calls to do operations on opaque file handles that the file system
> controls. Exposing a completely meaningless "generation" is a bad idea.
>

The basic idea of generation numbers is to check if an inode was
recycled, so only if the tuple of inode-number and generation-number
matches we still have the same file. Kernel nfs uses that and unfs3 uses
it via EXT2_IOC_GETVERSION, which has the overhead of an additional
syscall. Unionfs-fuse usually keeps file open, however, it might run out
of the maximum allowed files and I plan to add a mode to close and
re-open files as failback mode. For that the definite knowledge if a
file/inode is still the very same and the inode was not just recycled is
crucial.

All of that being said, I think with open_by_handle_at() syscall we
don't need the inode generation number any more.

Cheers,
Bernd

2012-05-09 13:51:23

[permalink] [raw]

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

On 2012-05-09, at 6:25 AM, Bernd Schubert wrote:
> On 05/09/2012 02:05 PM, Christoph Hellwig wrote:
>> On Wed, May 09, 2012 at 01:55:16PM +0200, Bernd Schubert wrote:
>>> The basic idea of generation numbers is to check if an inode was
>>> recycled, so only if the tuple of inode-number and generation-number
>>> matches we still have the same file. Kernel nfs
>>
>> NFS does not and should not look at the inode generation. Except for a
>> bit of legacy code for the old pre-Linux 2.4 filehandles it looks at the
>> opaque file handle returned and only interpreted by the filesystem. Any
>> userspace NFS server should do the same.
>
> Ok, I didn't look how kernel NFS does it for quite some time already...
> User space NFS only can do it beginning with 2.6.39 - given that user space also needs to support older kernels and other OSs, which might not have open_by_handle, userspace unfortunately cannot entirely rely on that feature.

But even fewer kernels have sys_statxat() in them (i.e. none), so you can rely on that even less than open_by_handle()...

Cheers, Andreas

2012-05-09 01:16:30

[permalink] [raw]

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

On 2012-05-08, at 18:24, Dave Chinner <[email protected]> wrote:
> On Tue, May 08, 2012 at 09:19:42PM +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 */
>> uint64_t st_blocks; /* Number of 512-byte blocks allocated */
>> uint64_t st_gen; /* Inode generation number */
>
> I don't think we want to expose the inode generation numbers. It is
> trivial to construct NFS file handles (usually just fsid, inode
> number and generation) with that information and hence bypass
> security checks to access files.

At the same time, if the user can stay the file and get this information, that isn't making the sole any less secure than if they can access the file via NFS. They have already passed all of the pathname security checks by the time they can do a statxat() on the file.

>> 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:

One comment on this struct is that it would probably be better to use sx_ or sf_ as the prefix for these fields.

>> 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 */
>
> That's per file information, not per filesystem. XFS definitely
> needs this IO information per-file....

Definitely. Lustre can have wildly different layouts for each file. This will also avoid duplication of st_blksize in both the statx and statx_fsinfo structs.

The main question I have about these fields is what the difference is between st_blksize and st_alloc_blksize?

>> /* 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 */
>
> And there's all the remaining information needed to construct file
> NFS handles without root priviledges...
>
>> /* 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 */
>> };
>>
>> One could argue a bit over what goes in which, should we go for this. This
>> may be better split between multiple syscalls though (with the race that that
>> implies) and potentially merging with statfs.
>>
>>
>> The statxat() syscall [née xstat] could then use the 6th parameter thusly:
>>
>> asmlinkage long sys_statxat(int dfd, const char __user *path, unsigned flags,
>> unsigned mask, struct statx __user *buffer,
>> struct statx_fsinfo __user *fsinfo);
>>
>>
>> letting fsinfo be NULL to indicate a lack of interest. I'm not sure we want
>> to do that, though.
>>
>>
>> Also, do Dave Chinner's ideas for indicating five I/O parameters want to be
>> 32-bit numbers? Larger? Smaller? Can they be log2?
>
> Definitely 32 bit, IMO, as it's not uncommon to see optimal IO sizes
> in the tens of megabytes on large, high bandwidth storage systems.
> As for being log2 - that's just making it more complex to use and
> making code ugly - we'd have to convert to log2 in kernel, then
> convert back in every single application....
>
>> Note also, that I've suggested that we represent the timestamp granularity
>> information as a decimal float (which requires 3 bytes per timestamp) and that
>> we provide separate granularities for each timestamp.
>>
>> David
>>
>
> --
> Dave Chinner
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2012-05-10 09:52:23

[permalink] [raw]

Subject: Re: [PATCH 0/6] Extended file stat system call

Dave Chinner <[email protected]> wrote:

> st_blksize - file block size
> st_alloc_blksize - allocation block size/alignment
> st_small_io_size - IO size/alignment that avoids
> filesystem/page cache RMW
> st_preferred_io_size - preferred IO size for general
> usage.
> st_large_io_size - IO size/alignment for high
> bandwidth sequential IO

What is st_blksize here? Is it directly comparable (if such a thing is
possible) to st_blksize in struct stat? Or does st_preferred_io_size map to
the current st_blksize and your st_blksize map to actual media block size (and
if so, is that the same as st_alloc_blksize? - I presume st_alloc_blksize
must be a multiple of the media block size).

David

2012-05-09 14:13:13

by Bernd Schubert

[permalink] [raw]

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

On 05/09/2012 03:51 PM, Andreas Dilger wrote:
> On 2012-05-09, at 6:25 AM, Bernd Schubert wrote:
>> On 05/09/2012 02:05 PM, Christoph Hellwig wrote:
>>> On Wed, May 09, 2012 at 01:55:16PM +0200, Bernd Schubert wrote:
>>>> The basic idea of generation numbers is to check if an inode was
>>>> recycled, so only if the tuple of inode-number and generation-number
>>>> matches we still have the same file. Kernel nfs
>>>
>>> NFS does not and should not look at the inode generation. Except for a
>>> bit of legacy code for the old pre-Linux 2.4 filehandles it looks at the
>>> opaque file handle returned and only interpreted by the filesystem. Any
>>> userspace NFS server should do the same.
>>
>> Ok, I didn't look how kernel NFS does it for quite some time already...
>> User space NFS only can do it beginning with 2.6.39 - given that user space also needs to support older kernels and other OSs, which might not have open_by_handle, userspace unfortunately cannot entirely rely on that feature.
>
> But even fewer kernels have sys_statxat() in them (i.e. none), so you can rely on that even less than open_by_handle()...

Well, I didn't say that :) In summary, an application needs to try to
use the open-by-handle call and if that is not supported, it has to fall
back to traditional stat and generation-number-ioctl. And as I said
before, open-by-handle very likely removes the requirement for
generation numbers in sys_statxat().

Cheers,
Bernd

2012-05-09 09:22:03

[permalink] [raw]

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

Dave Chinner <[email protected]> wrote:

> I don't think we want to expose the inode generation numbers. It is
> trivial to construct NFS file handles (usually just fsid, inode
> number and generation) with that information and hence bypass
> security checks to access files.

I was asked for it by Bernd Schubert for userspace NFS servers and FUSE -
maybe he can say what he wants it for.

I also have a note that Jeremy Allison asked for it, but I can't find where or
why, so that might be an error.

It looks like FreeBSD do have an st_gen field in their stat struct, but it's
only filled in for root. Maybe I could do something like that?

David

2012-05-09 12:25:35

by Bernd Schubert

[permalink] [raw]

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

On 05/09/2012 02:05 PM, Christoph Hellwig wrote:
> On Wed, May 09, 2012 at 01:55:16PM +0200, Bernd Schubert wrote:
>> The basic idea of generation numbers is to check if an inode was
>> recycled, so only if the tuple of inode-number and generation-number
>> matches we still have the same file. Kernel nfs
>
> NFS does not and should not look at the inode generation. Except for a
> bit of legacy code for the old pre-Linux 2.4 filehandles it looks at the
> opaque file handle returned and only interpreted by the filesystem. Any
> userspace NFS server should do the same.

Ok, I didn't look how kernel NFS does it for quite some time already...
User space NFS only can do it beginning with 2.6.39 - given that user
space also needs to support older kernels and other OSs, which might not
have open_by_handle, userspace unfortunately cannot entirely rely on
that feature.

Cheers,
Bernd

2012-05-09 11:14:33

[permalink] [raw]

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

On Wed, May 09, 2012 at 02:25:32PM +1000, Dave Chinner wrote:
> On Tue, May 08, 2012 at 09:09:41PM -0400, J. Bruce Fields wrote:
> > On Wed, May 09, 2012 at 10:24:20AM +1000, Dave Chinner wrote:
> > > On Tue, May 08, 2012 at 09:19:42PM +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 */
> > > > uint64_t st_blocks; /* Number of 512-byte blocks allocated */
> > > > uint64_t st_gen; /* Inode generation number */
> > >
> > > I don't think we want to expose the inode generation numbers. It is
> > > trivial to construct NFS file handles (usually just fsid, inode
> > > number and generation) with that information and hence bypass
> > > security checks to access files.
> >
> > I'm not convinced there's much value in trying to keep filehandles
> > secret.
>
> Sure, but I can't really see any good reason to expose filesystem
> internal implementation details like this - a generation number is
> usually used to differentiate between inode life cycles which
> userspace has no concept of and is different for every filesystem,
> so it's behaviour and values are not going to be consistent across
> filesystems.

That's OK. The only requirement would be that the (inode number, inode
generation) pair be different for different inodes on the same
filesystem.

> Some filesystems might not even have a generation
> number they can export, and that makes me wonder if there is any
> good reason for exposing it at all.

That's true of a number of these new attributes.

> If you need to discriminate between versions of files with the same
> name, then use name_to_handle_at() and compare filehandles....

Sure.

Since the only use case given for this has been constructing
filehandles, and since we already have an interface for that, I don't
feel particularly strongly about this.

--b.

2012-05-09 12:05:56

by Christoph Hellwig

[permalink] [raw]

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

On Wed, May 09, 2012 at 01:55:16PM +0200, Bernd Schubert wrote:
> The basic idea of generation numbers is to check if an inode was
> recycled, so only if the tuple of inode-number and generation-number
> matches we still have the same file. Kernel nfs

NFS does not and should not look at the inode generation. Except for a
bit of legacy code for the old pre-Linux 2.4 filehandles it looks at the
opaque file handle returned and only interpreted by the filesystem. Any
userspace NFS server should do the same.

2012-05-08 20:20:33

[permalink] [raw]

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

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 */
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 */
};

One could argue a bit over what goes in which, should we go for this. This
may be better split between multiple syscalls though (with the race that that
implies) and potentially merging with statfs.

The statxat() syscall [née xstat] could then use the 6th parameter thusly:

asmlinkage long sys_statxat(int dfd, const char __user *path, unsigned flags,
unsigned mask, struct statx __user *buffer,
struct statx_fsinfo __user *fsinfo);

letting fsinfo be NULL to indicate a lack of interest. I'm not sure we want
to do that, though.

Also, do Dave Chinner's ideas for indicating five I/O parameters want to be
32-bit numbers? Larger? Smaller? Can they be log2?

Note also, that I've suggested that we represent the timestamp granularity
information as a decimal float (which requires 3 bytes per timestamp) and that
we provide separate granularities for each timestamp.

David

2012-05-09 11:20:43

by Christoph Hellwig

[permalink] [raw]

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

On Wed, May 09, 2012 at 10:21:14AM +0100, David Howells wrote:
> Dave Chinner <[email protected]> wrote:
>
> > I don't think we want to expose the inode generation numbers. It is
> > trivial to construct NFS file handles (usually just fsid, inode
> > number and generation) with that information and hence bypass
> > security checks to access files.
>
> I was asked for it by Bernd Schubert for userspace NFS servers and FUSE -
> maybe he can say what he wants it for.

It's entirely broken, as a generation number might be part of the file
handle (and for Linux-like filesystems normally is), but it's entirely
up to the filesystem to decide how it works. That's why we added system
calls to do operations on opaque file handles that the file system
controls. Exposing a completely meaningless "generation" is a bad idea.

2012-05-09 04:26:03

[permalink] [raw]

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

On Tue, May 08, 2012 at 09:09:41PM -0400, J. Bruce Fields wrote:
> On Wed, May 09, 2012 at 10:24:20AM +1000, Dave Chinner wrote:
> > On Tue, May 08, 2012 at 09:19:42PM +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 */
> > > uint64_t st_blocks; /* Number of 512-byte blocks allocated */
> > > uint64_t st_gen; /* Inode generation number */
> >
> > I don't think we want to expose the inode generation numbers. It is
> > trivial to construct NFS file handles (usually just fsid, inode
> > number and generation) with that information and hence bypass
> > security checks to access files.
>
> I'm not convinced there's much value in trying to keep filehandles
> secret.

Sure, but I can't really see any good reason to expose filesystem
internal implementation details like this - a generation number is
usually used to differentiate between inode life cycles which
userspace has no concept of and is different for every filesystem,
so it's behaviour and values are not going to be consistent across
filesystems. Some filesystems might not even have a generation
number they can export, and that makes me wonder if there is any
good reason for exposing it at all.

If you need to discriminate between versions of files with the same
name, then use name_to_handle_at() and compare filehandles....

Cheers,

Dave.

--
Dave Chinner
[email protected]

2012-05-10 16:05:30

[permalink] [raw]

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

On 2012-05-10, at 3:23 AM, David Howells wrote:
> Andreas Dilger <[email protected]> wrote:
>> The main question I have about these fields is what the difference is
>> between st_blksize and st_alloc_blksize?
>
> I would assume that st_blksize is some ideal I/O size, not the
> allocation block size.

But there are several optimal IO sizes, so unless there is a clear
description of what each of these fields is intended to be used for,
it doesn't make sense to add them in.

> Dave Chinner might be able to answer better as he suggested these
> I/O information fields.
>
> David

Cheers, Andreas

2012-05-10 09:23:50