On the other thread we can discuss the configuration file parser used, this other thread we can use for the sysfs knobs and if it makes sense to share anything in consideration for a possible future udev event. More below. On Thu, Aug 24, 2017 at 08:04:41PM +0200, Luis R. Rodriguez wrote: > On Thu, Aug 24, 2017 at 10:10:28AM -0700, Darrick J. Wong wrote: > > It might be useful to send kobject_uevent_env so that we can squeeze in > > things like the fs uuid for easier identification? I envision a > > /etc/xfs/fs.conf file like this: > > > > [903db5b1-82cd-4f26-8221-443a4ed0563a] > > error.metadata.EIO.max_retries = 0 > > error.fail_at_unmount = 1 > > config.cowextsize = 1048576 > > config.inherit_noatime = 1 > > > > With a udev helper that uses the fsuuid to find the appropriate section > > of the ini^Wconfig file and load the appropriate values into sysfs. > > 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, <-- udev thing and now snip --> > Just saying, we better damn be sure this is the way we want to go. > > > > + if (err) > > > + xfs_notice(mp, "Sending XFS uevent %d got error %d", > > > + action, err); > > > +} > > > + > > > STATIC int > > > xfs_fs_fill_super( > > > struct super_block *sb, > > > @@ -1667,6 +1680,8 @@ xfs_fs_fill_super( > > > goto out_unmount; > > > } > > > > > > + xfs_fs_uevent(mp, KOBJ_ONLINE); > > > > That said, I wonder if we ought to move this discussion to fsdevel to > > pull in any /other/ filesystems that have sysfs knobs that they might > > like to be able to persist? ext4 has a bunch of tunables too... So were you thinking perhaps if we are going to use udev that it may make sense then to instead consider if we want to share tunables for uevents? Then instead of each filesystem having its own parser, etc, we have set of common knobs for any filesystem possible. Is that what you had in mind to discuss? Luis
