Date: Sat, 05 Oct 2002 10:56:30 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Dima Dorfman <dima@trit.org> Cc: fs@FreeBSD.ORG, rwatson@FreeBSD.ORG Subject: Re: Retrieving filesystem-specific mount parameters from the kernel Message-ID: <9511.1033808190@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 05 Oct 2002 06:48:10 -0000." <20021005064810.GF26530@trit.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. At least IMO. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?9511.1033808190>