(Sorry for top post) Ah, note that by "glusterfs.<something>" i was meaning "<ns>.glusterfs.<something>" where <ns> is like "user". It just needs to be a mechanism to store key values on the inode. Avati Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Myklebust, Trond [Trond.Myklebust@xxxxxxxxxx] Received: Monday, 28 Oct 2013, 18:52 To: Anand Avati [aavati@xxxxxxxxxx] CC: Wheeler Ric [rwheeler@xxxxxxxxxx]; Dr Fields James Bruce [bfields@xxxxxxxxxx]; Christoph Anton Mitterer [calestyo@xxxxxxxxxxxx]; Mailing List Linux NFS [linux-nfs@xxxxxxxxxxxxxxx]; Dickson Steve [steved@xxxxxxxxxx] Subject: Re: XATTRs in NFS? On Oct 28, 2013, at 9:24 PM, Anand Avati <aavati@xxxxxxxxxx> wrote: > On 10/28/2013 06:26 PM, Myklebust, Trond wrote: > >> >> That battle may have been fought and won within the glusterfs community, but why should we wave the white flag without a discussion? I don't see how what he described above has anything to do with user defined attributes. He's describing how he wants to export quota information and xtime through a private xattr interface that is currently unique to glusterfs. How is that not a private syscall interface? >> > > Exposing quota informtion is use "from the top". Note the other point I mention about using NFS volumes as "gluster bricks" where we store xattrs as dumb and persistent key/values associated with file/dir inodes (fresh/stale info for replication, hash ranges for dirs, quota acconting info per-dir, xtime per dir). >> Which of the mainstream filesystems have their own private xattr namespaces like the above? >> > > Why should NFS need to worry? As long as it acts like a pass-through (like every other call it supports). We need to worry because we don't know what side-effects your private interface will have. How does it affect our caching model? How do we debug any problems that arise? Are there any security implications that we need to know about? Trond
