Mailinglist Archive: opensuse (4054 mails)

[Randall R Schulz <rschulz@xxxxxxxxx>]

Anders,

On Saturday 07 January 2006 16:20, Anders Johansson wrote:
> On Sunday 08 January 2006 01:07, Randall R Schulz wrote:
> > Well, it does not behave like a hard link, either. For one thing,
> > hard links (directory entries) are just <name, inode-number> pairs,
> > and the file system in which the inode number is looked up is
> > implicitly that of the directory containing the directory entry
> > from which the inode number was read.
>
> I said it behaved like one, I didn't say it was one. And it does
> behave like one

I disagree. It doesn't behave like anything at all, since it does not 
exist at all. Not the way any real file system does, with disk blocks, 
inodes and a directory tree. The /proc pseudo-file system is just a 
stylized way of presenting kernel data structures.


> > Besides, for files (inodes) with no directory entries referring to
> > them, it's the internal reference count on the kernel-resident
> > inode structure that prevents reclamation of the inode and its
> > resources (disk blocks), not a faked up directory entry in the proc
> > pseudo-file system.
>
> huh? When the "faked up" entry in /proc is created it increments the
> counter in the inode structure. Where is the contradiction?

That pseudo-entry in that pseudo-file system is not the internal inode 
table and it is the reference count in the inode table reaching zero 
that initiates reclamation of the file's disk resources. Even if 
that /proc/pid/fd entries did not exist (and they don't), it is the 
fact that a process has an open file table entry pointing to the inode 
table entry that prevents inodes with no referring directory entries 
from being reclaimed.

Again, the entries in /proc are just a way of presenting the information 
from kernel data structures in a manner easily visible to user-level 
code. They are not primary entities the way actual directory entries 
are.

Randall Schulz