From: Dave Chinner <david@fromorbit.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Hou Tao <houtao1@huawei.com>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Jeff Mahoney <jeffm@suse.com>, NeilBrown <neilb@suse.com>,
Tso Ted <tytso@mit.edu>, Dmitri Pal <dpal@redhat.com>
Subject: Re: Filesystem configuration parsers - (was: Re: [RESEND][PATCH] xfs: add online uevent for mount operation)
Date: Fri, 25 Aug 2017 12:18:30 +1000 [thread overview]
Message-ID: <20170825021830.GM21024@dastard> (raw)
In-Reply-To: <20170825012001.GY27873@wotan.suse.de>
On Fri, Aug 25, 2017 at 03:20:01AM +0200, Luis R. Rodriguez wrote:
> On Fri, Aug 25, 2017 at 11:01:55AM +1000, Dave Chinner wrote:
> > On Thu, Aug 24, 2017 at 08:04:41PM +0200, Luis R. Rodriguez wrote:
> > > While all this is nice, I'm sure we're all aware of the dangers of setting
> > > things in stone through sysfs, its likely already decided for the above
> > > tunables, but adding a uevent *is* yet another layer of user interface
> > > which userspace can *expect* and we should be certain we want this so
> > > we won't regress userspace later.
> > >
> > > Just saying, we better damn be sure this is the way we want to go.
> >
> > I'm not sure what you are trying to warn us about? :/
> >
> > These are events on an XFS specific kobj, it's not a generic VFS
> > filesystem event we are generating here. It's no different from a
> > hardware device generating it's own uevents to tell userspace
> > something changed in the device.
>
> I meant that once its sent even if it is XFS specific, it will be
> something that some userspace can expect and then we'd always have
> to send it later.
Well, yes. Just like we have to support ioctls, /proc and /sysfs
interfaces and the quota event interface essentially forever.
There's nothing new or difficult about that.
> > A quick grep would have told you that GFS2 already has it's own
> > online/offline uevents (e.g. gfs2_online_uevent()), as does the
> > DLM code. Orangefs seems to use quite a few of uevent notifications,
> > too. So it's not like we're doing something controversial or unique
> > here, nor something that locks us out of a non-existent VFS event
> > notification mechanism.
>
> I don't think its controversial *at all*. Just that a mount uevent,
> with uuid, sounds like something we could at least agree is pretty generic.
Yeah, right. Call me cynical, but every single time this has been
brought up it devolves into a paint-fest where everyone wants
something to be added before anything can be done because generic
filesystem events is a deep, dark complex hole. e.g. think of bind
mounts: go and develop arguments for and against whether we should
send generic mount notifications for bind mounts. Generic doesn't
mean simple.
IOWs, what you describe as "pretty generic", I see as "a great big
can of worms".
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-08-25 2:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 13:41 [RESEND][PATCH] xfs: add online uevent for mount operation Hou Tao
2017-08-24 17:10 ` Darrick J. Wong
2017-08-24 18:04 ` Filesystem configuration parsers - (was: Re: [RESEND][PATCH] xfs: add online uevent for mount operation) Luis R. Rodriguez
2017-08-24 18:13 ` Luis R. Rodriguez
2017-08-24 18:59 ` Luis R. Rodriguez
2017-08-24 22:11 ` NeilBrown
2017-08-24 22:39 ` Luis R. Rodriguez
2017-08-24 23:34 ` Theodore Ts'o
2017-08-25 0:02 ` Luis R. Rodriguez
2017-08-25 4:54 ` Darrick J. Wong
2017-08-25 1:01 ` Dave Chinner
2017-08-25 1:20 ` Luis R. Rodriguez
2017-08-25 2:18 ` Dave Chinner [this message]
2017-08-25 5:29 ` Darrick J. Wong
2017-08-25 0:27 ` [RESEND][PATCH] xfs: add online uevent for mount operation Dave Chinner
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=20170825021830.GM21024@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=dpal@redhat.com \
--cc=houtao1@huawei.com \
--cc=jeffm@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=neilb@suse.com \
--cc=tytso@mit.edu \
/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.