linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
	David Howells <dhowells@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-afs@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] afs: Add metadata xattrs
Date: Sat, 8 Jul 2017 21:01:55 -0400	[thread overview]
Message-ID: <20170709010155.3nql5ixdeozemgfd@thunk.org> (raw)
In-Reply-To: <CA+55aFyFEW8LTEoyckW2YNeMrk5q_FweRsGbZKxXHWQjGLRw8w@mail.gmail.com>

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

  reply	other threads:[~2017-07-09  1:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <149935261019.29744.8564287571048506851.stgit@warthog.procyon.org.uk>
     [not found] ` <149935262759.29744.6299062653432480230.stgit@warthog.procyon.org.uk>
2017-07-06 15:23   ` [PATCH 2/2] afs: Add metadata xattrs Christoph Hellwig
2017-07-06 16:14   ` David Howells
2017-07-06 18:27     ` Andreas Dilger
2017-07-08 19:44       ` Linus Torvalds
2017-07-09  1:01         ` Theodore Ts'o [this message]
     [not found]           ` <20170709010155.3nql5ixdeozemgfd-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-09  2:37             ` Jeffrey Altman

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=20170709010155.3nql5ixdeozemgfd@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).