On Fri, Aug 25, 2017 at 08:11:05AM +1000, NeilBrown wrote:
> On Thu, Aug 24 2017, Luis R. Rodriguez wrote:
> >
> > Just saying, we better damn be sure this is the way we want to go.
> >
>
> Just to provide contrast, NFS has a config file which can provide
> certain defaults for mounted filesystems. However it doesn't require a
> udev event to achieve this.
>
> Instead, it provides "/sbin/mount.nfs" which imposes the defaults at
> mount time, rather than just after mount time.
>
> There could, conceivably, be an "/sbin/mount.xfs" which read the config
> file and set all the defaults concurrently with the mount operation.
>
> I'm not necessarily saying this is a better way to go, but I agree with
> the need to be sure, and this provides evidence that other approaches
> are possible and worth considering.
I like the NFS approach given:
o It would mean you can keep things contained within each filesystem
userspace tool. This would not escalate the requirements for what
parser to use, ie we would not need to pick one for a higher level
language for udev rules. Tools which already have a parser
like e2fsprogs can keep on chugging with libprofile, meanwhile XFS and
others can choose whatever library their own heart pleases and the
requirement still remains just simple file parsing, not needing
higher level language support.
o One advantage of having things like /sbin/mount.<filesystem> is
shared filesystems between a type of system can be kept separately
from host specific mount points. This could allow sharing *one* file
for a type of target system (database, development, etc). There
would not be any need to look for your own filesystem in /etc/fstab,
or adding entries, then /etc/fstab would just become very host specific.
o Custom entries can be supported without having to worry about
breaking parsing of the general /etc/fstab, it also removes clutter
from complex lines and entries out of /etc/fstab
Are there other needs for uevents which could not be addressed through
a filesystem configuration file or which prove more efficient or provide
more flexibility?
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
