From owner-freebsd-fs Fri Sep 20 04:57:28 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27941 for fs-outgoing; Fri, 20 Sep 1996 04:57:28 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA26438 for ; Fri, 20 Sep 1996 04:54:18 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id MAA05014; Fri, 20 Sep 1996 12:47:15 +0100 Date: Fri, 20 Sep 1996 12:47:14 +0100 (BST) From: Doug Rabson To: Robert Nordier cc: freebsd-fs@FreeBSD.ORG Subject: Re: [Q]: Is VFS_VGET filesystem-specific? In-Reply-To: <199609191859.UAA01168@eac.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 19 Sep 1996, Robert Nordier wrote: > Is VFS_VGET intended as a filesystem-specific function -- only for > filesystems actually using inodes -- or does it make sense to > implement it anyway, if it can be supported? > > int (*vfs_vget)(struct mount *mp, > ino_t ino, > struct vnode **vpp); > > The vfatfs makes use of a 'dnode' structure largely identical to > an inode, except that quota info is missing (can't be supported) > and the 'dinode' section differs (reflecting the much simpler DOS > directory entry structure). > > The 'dnode' dn_number is equivalent to an inode i_number, with > ROOTDNO == ROOTINO, etc, and vfatfs_vget() is currently used in > much the same way ffs_vget() is. > > Of course, it would be easy enough to rename the current vfatfs_vget(), > make it static, and just return EOPNOTSUPP. VFS_VGET is mainly used internally by inode-based filesystems like UFS. It can be called from the NFS server to support the READDIRPLUS request which interleaves directory entries and file attributes. The server uses VFS_VGET with the d_fileno from the directory entry to read the attributes. If VFS_VGET returns EOPNOTSUPP, then the server returns an appropriate status to force the client to retry with a normal READDIR. So I guess the answer is that you only need to implement it if you care about the performance of "ls -l" in large directories mounted over NFS. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426