Date: Mon, 05 Sep 2005 22:45:01 +0400 From: Igor Shmukler <shmukler@mail.ru> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru> Subject: Re[2]: vn_fullpath() again Message-ID: <E1ECLxl-00003m-00.shmukler-mail-ru@f41.mail.ru> In-Reply-To: <20050905175709.H88940@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert, You are correct about the Unix file system organization, but does it mean reliable vnode to fullname conversation is not possible? As long as vnode is referenced we should be able to perform the lookup for any file system. Linux does a pretty good job with d_path() and I understand Matt changed his NC to provide this. The FreeBSD name cache requires work. It could and IMHO should be improved. If there is a desire to have FreeBSD improved in this area, why doesn't someone look at a solution I submitted for returning devfs names. While a perfect solution would require serious changes to the OS, a solution that would work for referenced vnodes is easier to implement. igor. -----Original Message----- From: Robert Watson <rwatson@FreeBSD.org> To: Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru> Date: Mon, 5 Sep 2005 18:00:56 +0100 (BST) Subject: Re: vn_fullpath() again > > On Mon, 5 Sep 2005, Sergey Uvarov wrote: > > > all knows that vn_fullpath() is unreliable. However I really need to get > > a filename for a given vnode. To simplify the task, I do not care of > > synthetic file systems or hardlinks. > > > > I have looked through archives in hope to find a better solution. It > > seems that linux_getcwd() approach could help. However to make that code > > work for me, I need to know a directory vnode where the file resides. > > vnode->v_dd field looks promising. But as I understand it did not help > > if file name is not in a name cache. > > > > So the question: is it ever possible to get directory vnode for a given > > file vnode? > > One way to look at the problem is from the perspective of how you might > derive that information from an on-disk inode. If you look at the UFS > layout on-disk, you'll see that there is no pointer to a directory back > from a leaf inode; in kernel, you can have a reference to a vnode with no > back pointer to a directory vnode. In order to find the parent, you > potentially have to iterate through all directories on the hard disk > looking for the parent, which is a potentially long-running activity. > It's also not at all theoretical: vnodes are often accessed without any > path lookup at all. For example, background fsck may pull inodes off disk > without a name lookup, and the NFS server can receive file handle > references following a reboot from a live client that maintains cached > references -- it will service them without performing a lookup. > > So unfortunately, the answer is complex: (a) you may have to search the > disk for a name, and (b) you may not even find one, since there can be > files without any name at all (i.e., a temporary file that has been > unlinked). > > On non-UFS style file systems, such as HFS+, it is possible to generate a > path from the file system root without extensive disk I/O. However, all > common UNIX-like file systems don't have this property -- Sun's version of > UFS, ext2fs/ext3fs, and so on. > > If the child vnode is a directory, you can just follow it's '..' link or > covered vnode, of course... > > Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1ECLxl-00003m-00.shmukler-mail-ru>