Date: Mon, 7 Oct 2002 23:51:58 +0000 From: Dima Dorfman <dima@trit.org> To: Robert Watson <rwatson@freebsd.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, fs@freebsd.org, mux@freebsd.org Subject: Re: Retrieving filesystem-specific mount parameters from the kernel Message-ID: <20021007235157.GA25653@trit.org> In-Reply-To: <Pine.NEB.3.96L.1021006225224.10328C-100000@fledge.watson.org> References: <9511.1033808190@critter.freebsd.dk> <Pine.NEB.3.96L.1021006225224.10328C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@FreeBSD.ORG> wrote: > > On Sat, 5 Oct 2002, Poul-Henning Kamp wrote: > > > In message <20021005064810.GF26530@trit.org>, Dima Dorfman writes: > > >[ rwatson cc'd because I want him to be aware of this possible abuse > > > of extended attributes. ] > > > > > >It is occasionally desirable to display filesystem-specific mount > > >parameters in the output of mount(8). For example, it would be useful > > >if one could tell whether an NFS mount was tcp or udp, v2 or v3, etc.; > > >likewise, it would be useful if one could tell which ruleset is > > >associated with a particular devfs mount. This kind of information is > > >traditionally included in 'struct statfs', but this doesn't scale well > > >(since it requires breaking the ABI whenever we add a new filesystem) > > >and doesn't work at all for third-party filesystems. I propose for > > >the filesystem to export this information via an extended attribute > > >(idea courtesy of Boris Popov). This is entirely backwards and > > >forwards compatible, and is easy to implement even in third-party > > >filesystems. > > > > I am not at all thrilled by this. > > > > First off, mux@'s new mount facility is very flexible and extensible to > > when it comes to mount options, and none of the information you mention > > above are unable to use that facility, in fact it could be argued that > > they should specifically use it. I'm somewhat confused by this. As far as I can tell, nmount(2) passes mount options *into* the kernel, and I'm trying to get that information *out* of the kernel. If you're talking about exporting the information in mnt_opt through some other interface (such as mine), then I agree that it is a good idea, and actually considered implementing that as a "default" action if the filesystem didn't override it (e.g., vfs_stdgetextattr() that exports the information in mnt_opt). It is not sufficient to *just* do this, however, since some of the information we may want to export is not something that would be passed in via nmount(2) (e.g., devfs ruleset number, or something else which may change during runtime). For this reason, I explicitly did not call what I'm exporting mount "options", but rather "parameters" (I realize that "option" and "parameter" are very close in meaning--I just wanted a different word). > > Second, I think this is simply not the kind of information which > > extended attributes should be used for. Extended attributes are used to > > store additional administrative information about a particular vnode, > > not to report how the vnode is used or configured. > > I tend to agree -- without nmount(), extended attributes might very well > be the best way to export this information. However, with nmount(), we > now have the ability to export arbitrary mount meta-data using a flexible > interface, and that's probably the way we should be handling NFS > mountpoint meta-data. Again, I'm confused about how one should use nmount(2) to export data out of the kernel. Looking at the prototype, this doesn't look like it's possible, but if I missed something, I'd be grateful if someone would set me on the right track (source or documentation references would be helpful). Thanks, Dima. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021007235157.GA25653>