From owner-freebsd-fs Sat Oct 5 1:56:38 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DFA337B401; Sat, 5 Oct 2002 01:56:37 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33AC243E65; Sat, 5 Oct 2002 01:56:36 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g958uUpS009512; Sat, 5 Oct 2002 10:56:31 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dima Dorfman Cc: fs@FreeBSD.ORG, rwatson@FreeBSD.ORG Subject: Re: Retrieving filesystem-specific mount parameters from the kernel In-Reply-To: Your message of "Sat, 05 Oct 2002 06:48:10 -0000." <20021005064810.GF26530@trit.org> Date: Sat, 05 Oct 2002 10:56:30 +0200 Message-ID: <9511.1033808190@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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