Date: Sun, 6 Oct 2002 22:53:52 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Dima Dorfman <dima@trit.org>, fs@FreeBSD.ORG, mux@FreeBSD.ORG Subject: Re: Retrieving filesystem-specific mount parameters from the kernel Message-ID: <Pine.NEB.3.96L.1021006225224.10328C-100000@fledge.watson.org> In-Reply-To: <9511.1033808190@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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. That said, we definitely need this general capability: we just don't get enough useful information out of the current information export interfaces. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories 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?Pine.NEB.3.96L.1021006225224.10328C-100000>