Date: Fri, 20 Sep 1996 12:47:14 +0100 (BST) From: Doug Rabson <dfr@render.com> To: Robert Nordier <rnordier@iafrica.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: [Q]: Is VFS_VGET filesystem-specific? Message-ID: <Pine.BSF.3.95.960920124255.11343H-100000@minnow.render.com> In-Reply-To: <199609191859.UAA01168@eac.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.960920124255.11343H-100000>