From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail01.adl2.internode.on.net ([150.101.137.133]:30498 "EHLO ipmail01.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754191AbdHYCSf (ORCPT ); Thu, 24 Aug 2017 22:18:35 -0400 Date: Fri, 25 Aug 2017 12:18:30 +1000 From: Dave Chinner To: "Luis R. Rodriguez" Cc: "Darrick J. Wong" , Hou Tao , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jeff Mahoney , NeilBrown , Tso Ted , Dmitri Pal Subject: Re: Filesystem configuration parsers - (was: Re: [RESEND][PATCH] xfs: add online uevent for mount operation) Message-ID: <20170825021830.GM21024@dastard> References: <1503582115-37220-1-git-send-email-houtao1@huawei.com> <20170824171028.GF4796@magnolia> <20170824180441.GL27873@wotan.suse.de> <20170825010155.GK21024@dastard> <20170825012001.GY27873@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170825012001.GY27873@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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