[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170709010155.3nql5ixdeozemgfd@thunk.org>
Date: Sat, 8 Jul 2017 21:01:55 -0400
From: Theodore Ts'o <tytso@....edu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andreas Dilger <adilger@...ger.ca>,
David Howells <dhowells@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
linux-afs@...ts.infradead.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] afs: Add metadata xattrs
On Sat, Jul 08, 2017 at 12:44:54PM -0700, Linus Torvalds wrote:
> Yeah, I think attributes are likely much better than some random crazy
> ioctl interface. They can be listed with generic tools, and have
> various scripting interfaces in ways that ioctl's do not sanely have.
I personally don't have a particular problem with these xattrs. For
one thing, they are read-only. You use them just to find out the AFS
cell, the AFS "fid", and the AFS volume name.
I think the place where people will start getting nervous is when we
start adding "write-only" xattrs or where writing to an xattr causes a
side-effect to take place.
So using xattr's to set AFS quota's for a volume, or to tell a client
about a new AFS cell, or to tell the client kernel about the database
servers for an AFS cell --- that I think would be pretty ugly.
Since such API's affect global state, and not a per-file state, I
don't believe xattrs are a good substitute for everything that was
done with the AFS pioctl system call for other operating systems. For
those uses cases my personal opinion is that defining new Linux system
calls for such things would make a lot more sense.
Or maybe just use sysfs interfaces for such things, although that has
gotten abused in the past too....
- Ted
Powered by blists - more mailing lists