All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@primarydata.com>
To: David Howells <dhowells@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-afs@vger.kernel.org" <linux-afs@vger.kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"samba-technical@lists.samba.org"
	<samba-technical@lists.samba.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
Date: Mon, 9 May 2016 13:23:05 +0000	[thread overview]
Message-ID: <F0929075-BA72-4325-B47B-036EBD3B5935@primarydata.com> (raw)
In-Reply-To: <31651.1462798652@warthog.procyon.org.uk>






On 5/9/16, 08:57, "linux-nfs-owner@vger.kernel.org on behalf of David Howells" <linux-nfs-owner@vger.kernel.org on behalf of dhowells@redhat.com> wrote:

>Christoph Hellwig <hch@infradead.org> wrote:
>
>> > 	int ret = statx(int dfd,
>> > 			const char *filename,
>> > 			unsigned int flags,
>> > 			unsigned int mask,
>> > 			struct statx *buffer);
>> 
>> Please move the flags and mask after the buffer, similar to how all
>> the AT_ flags were added to the end for the statat calls.
>
>Sure, if you really want.
>
>> > AT_FORCE_ATTR_SYNC can be set in flags.  This will require a network
>> > filesystem to synchronise its attributes with the server.
>> > 
>> > AT_NO_ATTR_SYNC can be set in flags.  This will suppress synchronisation
>> > with the server in a network filesystem.  The resulting values should be
>> > considered approximate.
>> 
>> And what happens if neither is set?
>
>It does what stat() does now, whatever that is for each fs.  The assumption is
>that this might be used to emulate stat() from userspace.  However, we want to
>be able to make sure we get the two behaviours above.
>
>> > mask is a bitmask indicating the fields in struct statx that are of
>> > interest to the caller.  The user should set this to STATX_BASIC_STATS to
>> > get the basic set returned by stat().
>> 
>> No a very good name for the constant.  I don't really see how this macro
>> is useful to start with.
>
>It's the bits that correspond to all the data in the the current stat struct.
>So if you want to emulate stat(), you should pass this in mask.
>
>> And _ALL? sure, but what's basic?
>
>Actually, _ALL is perhaps the less useful of the two since the bitset is not
>closed.  OTOH - anything not in _ALL won't be listed explicitly in the
>structure, but would rather consume space space.
>
>> > st_gen is
>> > the inode generation number, st_btime is the file creation time, st_version
>> > is the data version number (i_version),
>> 
>> Please define semantics for st_gen and st_version.
>
>I've been asked to drop st_gen for security reasons.
>
>I can't offhand think of a way to define st_version (or i_version, for that
>matter) that would be consistent across all filesystems.  I would lean towards
>"gets incremented monotonically by 1 for each data write operation committed,
>but not for any metadata operations", but I'm fairly certain this won't jibe
>with disk operations.  So I can leave it out for now and bring it back if we
>find a real user for it.

The NFSv4 definition for the change attribute (which is mapped to i_version when IS_I_VERSION(inode) is true) is

"A value created by the server that the client can use to determine if
   file data, directory contents, or attributes of the object have been
   modified.  The server may return the object's time_metadata attribute
   for this attribute's value, but only if the file system object cannot
   be updated more frequently than the resolution of time_metadata."


IOW: it is a value that changes on all data and metadata operations, and with no monotonicity requirement. I’m pretty sure all userspace NFSv4 servers out there would like to access it (e.g. Ganesha, dCache).

>
>> > Time fields are split into separate seconds and nanoseconds fields to make
>> > packing easier and the granularities can be queried with the filesystem
>> > info system call.  Note that times will be negative if before 1970; in such
>> > a case, the nanosecond fields should also be negative if not zero.
>> 
>> Please coordinate with Arnd on the timespamp format - I'd hate to have
>> a different encoding than he plans for all y2028/64-bit-time_t syscalls
>> to be added soon.
>
>I have discussed this with him previously.
>
>> > 	STATX_VERSION		Want/got st_data_version
>> 
>> What is st_data_version?
>
>Sorry, that should've been st_version.  It got renamed.
>
>> > 	STATX_GEN		Want/got st_gen
>> > 	STATX_ALL_STATS		[All currently available stuff]
>> 
>> Where does the STATS_ come from?  Why no simply _ALL?
>
>Why not STATX_ALL_STATS?
>
>David
>--
>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
To: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: "linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org"
	<samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
Date: Mon, 9 May 2016 13:23:05 +0000	[thread overview]
Message-ID: <F0929075-BA72-4325-B47B-036EBD3B5935@primarydata.com> (raw)
In-Reply-To: <31651.1462798652-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 4461 bytes --]






On 5/9/16, 08:57, "linux-nfs-owner@vger.kernel.org on behalf of David Howells" <linux-nfs-owner@vger.kernel.org on behalf of dhowells@redhat.com> wrote:

>Christoph Hellwig <hch@infradead.org> wrote:
>
>> > 	int ret = statx(int dfd,
>> > 			const char *filename,
>> > 			unsigned int flags,
>> > 			unsigned int mask,
>> > 			struct statx *buffer);
>> 
>> Please move the flags and mask after the buffer, similar to how all
>> the AT_ flags were added to the end for the statat calls.
>
>Sure, if you really want.
>
>> > AT_FORCE_ATTR_SYNC can be set in flags.  This will require a network
>> > filesystem to synchronise its attributes with the server.
>> > 
>> > AT_NO_ATTR_SYNC can be set in flags.  This will suppress synchronisation
>> > with the server in a network filesystem.  The resulting values should be
>> > considered approximate.
>> 
>> And what happens if neither is set?
>
>It does what stat() does now, whatever that is for each fs.  The assumption is
>that this might be used to emulate stat() from userspace.  However, we want to
>be able to make sure we get the two behaviours above.
>
>> > mask is a bitmask indicating the fields in struct statx that are of
>> > interest to the caller.  The user should set this to STATX_BASIC_STATS to
>> > get the basic set returned by stat().
>> 
>> No a very good name for the constant.  I don't really see how this macro
>> is useful to start with.
>
>It's the bits that correspond to all the data in the the current stat struct.
>So if you want to emulate stat(), you should pass this in mask.
>
>> And _ALL? sure, but what's basic?
>
>Actually, _ALL is perhaps the less useful of the two since the bitset is not
>closed.  OTOH - anything not in _ALL won't be listed explicitly in the
>structure, but would rather consume space space.
>
>> > st_gen is
>> > the inode generation number, st_btime is the file creation time, st_version
>> > is the data version number (i_version),
>> 
>> Please define semantics for st_gen and st_version.
>
>I've been asked to drop st_gen for security reasons.
>
>I can't offhand think of a way to define st_version (or i_version, for that
>matter) that would be consistent across all filesystems.  I would lean towards
>"gets incremented monotonically by 1 for each data write operation committed,
>but not for any metadata operations", but I'm fairly certain this won't jibe
>with disk operations.  So I can leave it out for now and bring it back if we
>find a real user for it.

The NFSv4 definition for the change attribute (which is mapped to i_version when IS_I_VERSION(inode) is true) is

"A value created by the server that the client can use to determine if
   file data, directory contents, or attributes of the object have been
   modified.  The server may return the object's time_metadata attribute
   for this attribute's value, but only if the file system object cannot
   be updated more frequently than the resolution of time_metadata."


IOW: it is a value that changes on all data and metadata operations, and with no monotonicity requirement. I’m pretty sure all userspace NFSv4 servers out there would like to access it (e.g. Ganesha, dCache).

>
>> > Time fields are split into separate seconds and nanoseconds fields to make
>> > packing easier and the granularities can be queried with the filesystem
>> > info system call.  Note that times will be negative if before 1970; in such
>> > a case, the nanosecond fields should also be negative if not zero.
>> 
>> Please coordinate with Arnd on the timespamp format - I'd hate to have
>> a different encoding than he plans for all y2028/64-bit-time_t syscalls
>> to be added soon.
>
>I have discussed this with him previously.
>
>> > 	STATX_VERSION		Want/got st_data_version
>> 
>> What is st_data_version?
>
>Sorry, that should've been st_version.  It got renamed.
>
>> > 	STATX_GEN		Want/got st_gen
>> > 	STATX_ALL_STATS		[All currently available stuff]
>> 
>> Where does the STATS_ come from?  Why no simply _ALL?
>
>Why not STATX_ALL_STATS?
>
>David
>--
>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±û"žØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br	šê+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹\x1e®w¥¢¸?™¨è­Ú&¢)ߢ^[f

WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@primarydata.com>
To: David Howells <dhowells@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-afs@vger.kernel.org" <linux-afs@vger.kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"samba-technical@lists.samba.org"
	<samba-technical@lists.samba.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
Date: Mon, 9 May 2016 13:23:05 +0000	[thread overview]
Message-ID: <F0929075-BA72-4325-B47B-036EBD3B5935@primarydata.com> (raw)
In-Reply-To: <31651.1462798652@warthog.procyon.org.uk>

DQoNCg0KDQoNCk9uIDUvOS8xNiwgMDg6NTcsICJsaW51eC1uZnMtb3duZXJAdmdlci5rZXJuZWwu
b3JnIG9uIGJlaGFsZiBvZiBEYXZpZCBIb3dlbGxzIiA8bGludXgtbmZzLW93bmVyQHZnZXIua2Vy
bmVsLm9yZyBvbiBiZWhhbGYgb2YgZGhvd2VsbHNAcmVkaGF0LmNvbT4gd3JvdGU6DQoNCj5DaHJp
c3RvcGggSGVsbHdpZyA8aGNoQGluZnJhZGVhZC5vcmc+IHdyb3RlOg0KPg0KPj4gPiAJaW50IHJl
dCA9IHN0YXR4KGludCBkZmQsDQo+PiA+IAkJCWNvbnN0IGNoYXIgKmZpbGVuYW1lLA0KPj4gPiAJ
CQl1bnNpZ25lZCBpbnQgZmxhZ3MsDQo+PiA+IAkJCXVuc2lnbmVkIGludCBtYXNrLA0KPj4gPiAJ
CQlzdHJ1Y3Qgc3RhdHggKmJ1ZmZlcik7DQo+PiANCj4+IFBsZWFzZSBtb3ZlIHRoZSBmbGFncyBh
bmQgbWFzayBhZnRlciB0aGUgYnVmZmVyLCBzaW1pbGFyIHRvIGhvdyBhbGwNCj4+IHRoZSBBVF8g
ZmxhZ3Mgd2VyZSBhZGRlZCB0byB0aGUgZW5kIGZvciB0aGUgc3RhdGF0IGNhbGxzLg0KPg0KPlN1
cmUsIGlmIHlvdSByZWFsbHkgd2FudC4NCj4NCj4+ID4gQVRfRk9SQ0VfQVRUUl9TWU5DIGNhbiBi
ZSBzZXQgaW4gZmxhZ3MuICBUaGlzIHdpbGwgcmVxdWlyZSBhIG5ldHdvcmsNCj4+ID4gZmlsZXN5
c3RlbSB0byBzeW5jaHJvbmlzZSBpdHMgYXR0cmlidXRlcyB3aXRoIHRoZSBzZXJ2ZXIuDQo+PiA+
IA0KPj4gPiBBVF9OT19BVFRSX1NZTkMgY2FuIGJlIHNldCBpbiBmbGFncy4gIFRoaXMgd2lsbCBz
dXBwcmVzcyBzeW5jaHJvbmlzYXRpb24NCj4+ID4gd2l0aCB0aGUgc2VydmVyIGluIGEgbmV0d29y
ayBmaWxlc3lzdGVtLiAgVGhlIHJlc3VsdGluZyB2YWx1ZXMgc2hvdWxkIGJlDQo+PiA+IGNvbnNp
ZGVyZWQgYXBwcm94aW1hdGUuDQo+PiANCj4+IEFuZCB3aGF0IGhhcHBlbnMgaWYgbmVpdGhlciBp
cyBzZXQ/DQo+DQo+SXQgZG9lcyB3aGF0IHN0YXQoKSBkb2VzIG5vdywgd2hhdGV2ZXIgdGhhdCBp
cyBmb3IgZWFjaCBmcy4gIFRoZSBhc3N1bXB0aW9uIGlzDQo+dGhhdCB0aGlzIG1pZ2h0IGJlIHVz
ZWQgdG8gZW11bGF0ZSBzdGF0KCkgZnJvbSB1c2Vyc3BhY2UuICBIb3dldmVyLCB3ZSB3YW50IHRv
DQo+YmUgYWJsZSB0byBtYWtlIHN1cmUgd2UgZ2V0IHRoZSB0d28gYmVoYXZpb3VycyBhYm92ZS4N
Cj4NCj4+ID4gbWFzayBpcyBhIGJpdG1hc2sgaW5kaWNhdGluZyB0aGUgZmllbGRzIGluIHN0cnVj
dCBzdGF0eCB0aGF0IGFyZSBvZg0KPj4gPiBpbnRlcmVzdCB0byB0aGUgY2FsbGVyLiAgVGhlIHVz
ZXIgc2hvdWxkIHNldCB0aGlzIHRvIFNUQVRYX0JBU0lDX1NUQVRTIHRvDQo+PiA+IGdldCB0aGUg
YmFzaWMgc2V0IHJldHVybmVkIGJ5IHN0YXQoKS4NCj4+IA0KPj4gTm8gYSB2ZXJ5IGdvb2QgbmFt
ZSBmb3IgdGhlIGNvbnN0YW50LiAgSSBkb24ndCByZWFsbHkgc2VlIGhvdyB0aGlzIG1hY3JvDQo+
PiBpcyB1c2VmdWwgdG8gc3RhcnQgd2l0aC4NCj4NCj5JdCdzIHRoZSBiaXRzIHRoYXQgY29ycmVz
cG9uZCB0byBhbGwgdGhlIGRhdGEgaW4gdGhlIHRoZSBjdXJyZW50IHN0YXQgc3RydWN0Lg0KPlNv
IGlmIHlvdSB3YW50IHRvIGVtdWxhdGUgc3RhdCgpLCB5b3Ugc2hvdWxkIHBhc3MgdGhpcyBpbiBt
YXNrLg0KPg0KPj4gQW5kIF9BTEw/IHN1cmUsIGJ1dCB3aGF0J3MgYmFzaWM/DQo+DQo+QWN0dWFs
bHksIF9BTEwgaXMgcGVyaGFwcyB0aGUgbGVzcyB1c2VmdWwgb2YgdGhlIHR3byBzaW5jZSB0aGUg
Yml0c2V0IGlzIG5vdA0KPmNsb3NlZC4gIE9UT0ggLSBhbnl0aGluZyBub3QgaW4gX0FMTCB3b24n
dCBiZSBsaXN0ZWQgZXhwbGljaXRseSBpbiB0aGUNCj5zdHJ1Y3R1cmUsIGJ1dCB3b3VsZCByYXRo
ZXIgY29uc3VtZSBzcGFjZSBzcGFjZS4NCj4NCj4+ID4gc3RfZ2VuIGlzDQo+PiA+IHRoZSBpbm9k
ZSBnZW5lcmF0aW9uIG51bWJlciwgc3RfYnRpbWUgaXMgdGhlIGZpbGUgY3JlYXRpb24gdGltZSwg
c3RfdmVyc2lvbg0KPj4gPiBpcyB0aGUgZGF0YSB2ZXJzaW9uIG51bWJlciAoaV92ZXJzaW9uKSwN
Cj4+IA0KPj4gUGxlYXNlIGRlZmluZSBzZW1hbnRpY3MgZm9yIHN0X2dlbiBhbmQgc3RfdmVyc2lv
bi4NCj4NCj5JJ3ZlIGJlZW4gYXNrZWQgdG8gZHJvcCBzdF9nZW4gZm9yIHNlY3VyaXR5IHJlYXNv
bnMuDQo+DQo+SSBjYW4ndCBvZmZoYW5kIHRoaW5rIG9mIGEgd2F5IHRvIGRlZmluZSBzdF92ZXJz
aW9uIChvciBpX3ZlcnNpb24sIGZvciB0aGF0DQo+bWF0dGVyKSB0aGF0IHdvdWxkIGJlIGNvbnNp
c3RlbnQgYWNyb3NzIGFsbCBmaWxlc3lzdGVtcy4gIEkgd291bGQgbGVhbiB0b3dhcmRzDQo+Imdl
dHMgaW5jcmVtZW50ZWQgbW9ub3RvbmljYWxseSBieSAxIGZvciBlYWNoIGRhdGEgd3JpdGUgb3Bl
cmF0aW9uIGNvbW1pdHRlZCwNCj5idXQgbm90IGZvciBhbnkgbWV0YWRhdGEgb3BlcmF0aW9ucyIs
IGJ1dCBJJ20gZmFpcmx5IGNlcnRhaW4gdGhpcyB3b24ndCBqaWJlDQo+d2l0aCBkaXNrIG9wZXJh
dGlvbnMuICBTbyBJIGNhbiBsZWF2ZSBpdCBvdXQgZm9yIG5vdyBhbmQgYnJpbmcgaXQgYmFjayBp
ZiB3ZQ0KPmZpbmQgYSByZWFsIHVzZXIgZm9yIGl0Lg0KDQpUaGUgTkZTdjQgZGVmaW5pdGlvbiBm
b3IgdGhlIGNoYW5nZSBhdHRyaWJ1dGUgKHdoaWNoIGlzIG1hcHBlZCB0byBpX3ZlcnNpb24gd2hl
biBJU19JX1ZFUlNJT04oaW5vZGUpIGlzIHRydWUpIGlzDQoNCiJBIHZhbHVlIGNyZWF0ZWQgYnkg
dGhlIHNlcnZlciB0aGF0IHRoZSBjbGllbnQgY2FuIHVzZSB0byBkZXRlcm1pbmUgaWYNCiAgIGZp
bGUgZGF0YSwgZGlyZWN0b3J5IGNvbnRlbnRzLCBvciBhdHRyaWJ1dGVzIG9mIHRoZSBvYmplY3Qg
aGF2ZSBiZWVuDQogICBtb2RpZmllZC4gIFRoZSBzZXJ2ZXIgbWF5IHJldHVybiB0aGUgb2JqZWN0
J3MgdGltZV9tZXRhZGF0YSBhdHRyaWJ1dGUNCiAgIGZvciB0aGlzIGF0dHJpYnV0ZSdzIHZhbHVl
LCBidXQgb25seSBpZiB0aGUgZmlsZSBzeXN0ZW0gb2JqZWN0IGNhbm5vdA0KICAgYmUgdXBkYXRl
ZCBtb3JlIGZyZXF1ZW50bHkgdGhhbiB0aGUgcmVzb2x1dGlvbiBvZiB0aW1lX21ldGFkYXRhLiIN
Cg0KDQpJT1c6IGl0IGlzIGEgdmFsdWUgdGhhdCBjaGFuZ2VzIG9uIGFsbCBkYXRhIGFuZCBtZXRh
ZGF0YSBvcGVyYXRpb25zLCBhbmQgd2l0aCBubyBtb25vdG9uaWNpdHkgcmVxdWlyZW1lbnQuIEni
gJltIHByZXR0eSBzdXJlIGFsbCB1c2Vyc3BhY2UgTkZTdjQgc2VydmVycyBvdXQgdGhlcmUgd291
bGQgbGlrZSB0byBhY2Nlc3MgaXQgKGUuZy4gR2FuZXNoYSwgZENhY2hlKS4NCg0KPg0KPj4gPiBU
aW1lIGZpZWxkcyBhcmUgc3BsaXQgaW50byBzZXBhcmF0ZSBzZWNvbmRzIGFuZCBuYW5vc2Vjb25k
cyBmaWVsZHMgdG8gbWFrZQ0KPj4gPiBwYWNraW5nIGVhc2llciBhbmQgdGhlIGdyYW51bGFyaXRp
ZXMgY2FuIGJlIHF1ZXJpZWQgd2l0aCB0aGUgZmlsZXN5c3RlbQ0KPj4gPiBpbmZvIHN5c3RlbSBj
YWxsLiAgTm90ZSB0aGF0IHRpbWVzIHdpbGwgYmUgbmVnYXRpdmUgaWYgYmVmb3JlIDE5NzA7IGlu
IHN1Y2gNCj4+ID4gYSBjYXNlLCB0aGUgbmFub3NlY29uZCBmaWVsZHMgc2hvdWxkIGFsc28gYmUg
bmVnYXRpdmUgaWYgbm90IHplcm8uDQo+PiANCj4+IFBsZWFzZSBjb29yZGluYXRlIHdpdGggQXJu
ZCBvbiB0aGUgdGltZXNwYW1wIGZvcm1hdCAtIEknZCBoYXRlIHRvIGhhdmUNCj4+IGEgZGlmZmVy
ZW50IGVuY29kaW5nIHRoYW4gaGUgcGxhbnMgZm9yIGFsbCB5MjAyOC82NC1iaXQtdGltZV90IHN5
c2NhbGxzDQo+PiB0byBiZSBhZGRlZCBzb29uLg0KPg0KPkkgaGF2ZSBkaXNjdXNzZWQgdGhpcyB3
aXRoIGhpbSBwcmV2aW91c2x5Lg0KPg0KPj4gPiAJU1RBVFhfVkVSU0lPTgkJV2FudC9nb3Qgc3Rf
ZGF0YV92ZXJzaW9uDQo+PiANCj4+IFdoYXQgaXMgc3RfZGF0YV92ZXJzaW9uPw0KPg0KPlNvcnJ5
LCB0aGF0IHNob3VsZCd2ZSBiZWVuIHN0X3ZlcnNpb24uICBJdCBnb3QgcmVuYW1lZC4NCj4NCj4+
ID4gCVNUQVRYX0dFTgkJV2FudC9nb3Qgc3RfZ2VuDQo+PiA+IAlTVEFUWF9BTExfU1RBVFMJCVtB
bGwgY3VycmVudGx5IGF2YWlsYWJsZSBzdHVmZl0NCj4+IA0KPj4gV2hlcmUgZG9lcyB0aGUgU1RB
VFNfIGNvbWUgZnJvbT8gIFdoeSBubyBzaW1wbHkgX0FMTD8NCj4NCj5XaHkgbm90IFNUQVRYX0FM
TF9TVEFUUz8NCj4NCj5EYXZpZA0KPi0tDQo+VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6
IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LW5mcyIgaW4NCj50aGUgYm9keSBvZiBh
IG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPk1vcmUgbWFqb3Jkb21vIGlu
Zm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KPg0K


  reply	other threads:[~2016-05-09 13:39 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
2016-05-02 22:46   ` Andreas Dilger
2016-05-02 22:46     ` Andreas Dilger
2016-05-03 15:53   ` David Howells
2016-05-04 22:56   ` Dave Chinner
2016-05-05  0:09     ` NeilBrown
2016-05-05  0:09       ` NeilBrown
2016-05-05 19:48       ` Jeff Layton
2016-05-06 18:07         ` J. Bruce Fields
2016-05-06 18:07           ` J. Bruce Fields
2016-05-05 20:04       ` David Howells
2016-05-05 20:04         ` David Howells
2016-05-06  1:39         ` Dave Chinner
2016-05-06  1:39           ` Dave Chinner
2016-05-06  1:39           ` Dave Chinner
2016-05-06 18:29     ` J. Bruce Fields
2016-05-09  1:45       ` Dave Chinner
2016-05-09  2:46         ` J. Bruce Fields
2016-05-04 23:56   ` NeilBrown
2016-05-08  8:35   ` Christoph Hellwig
2016-05-08  8:35     ` Christoph Hellwig
2016-05-09 12:02     ` Jeff Layton
2016-05-09 12:02       ` Jeff Layton
2016-05-10  7:00       ` Christoph Hellwig
2016-05-10  7:00         ` Christoph Hellwig
2016-05-10 13:21         ` Jeff Layton
2016-05-10 13:21           ` Jeff Layton
2016-05-09 12:57   ` David Howells
2016-05-09 12:57     ` David Howells
2016-05-09 13:23     ` Trond Myklebust [this message]
2016-05-09 13:23       ` Trond Myklebust
2016-05-09 13:23       ` Trond Myklebust
2016-05-10  7:04     ` Christoph Hellwig
2016-05-10  8:25     ` David Howells
2016-05-12  9:11       ` Christoph Hellwig
2016-05-13 15:28         ` Arnd Bergmann
2016-05-13 15:28           ` Arnd Bergmann
2016-05-23  8:22           ` Christoph Hellwig
2016-05-23  9:33           ` David Howells
2016-05-18 10:55         ` David Howells
2016-05-09 13:00   ` David Howells
2016-05-09 13:00     ` David Howells
2016-05-09 13:38   ` David Howells
2016-05-10  7:08     ` Christoph Hellwig
2016-05-10  8:43     ` David Howells
2016-05-12  9:12       ` Christoph Hellwig
2016-05-09 13:40   ` David Howells
2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells
2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells
2016-05-02 22:48   ` Andreas Dilger
2016-05-03 20:24   ` David Howells
2016-05-03 20:24     ` David Howells
2016-05-08  8:38   ` Christoph Hellwig
2016-05-08  8:38     ` Christoph Hellwig
2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells
2016-05-02 22:48   ` Andreas Dilger
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
2016-05-02 22:52   ` Andreas Dilger
2016-10-03 21:03     ` Steve French
2016-10-03 21:03       ` Steve French
2016-05-03 20:23   ` David Howells
2016-05-08  8:39   ` Christoph Hellwig
2016-05-08  8:39     ` Christoph Hellwig
2016-04-29 12:58 ` [PATCH 6/6] statx: CIFS: Return enhanced attributes David Howells
2016-04-30 21:05 ` [RFC][PATCH 0/6] Enhanced file stat system call Jeff Layton
2016-04-30 21:05   ` Jeff Layton
2016-05-04 13:46 ` Arnd Bergmann
2016-05-04 13:46   ` Arnd Bergmann
2016-05-05 22:54   ` Steve French
2016-05-06  2:00     ` Steve French
2016-05-09 13:09       ` Arnd Bergmann
2016-05-09 13:09         ` Arnd Bergmann
2016-05-13 14:28         ` Richard Sharpe
2016-05-13 14:28           ` Richard Sharpe
2016-05-13 15:08           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F0929075-BA72-4325-B47B-036EBD3B5935@primarydata.com \
    --to=trondmy@primarydata.com \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-afs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.