Is vnode number also limit system-wide number of open file?
mkatiyar at gmail.com
Wed May 31 22:16:28 EDT 2017
On May 31, 2017 6:15 PM, "Yubin Ruan" <ablacktshirt at gmail.com> wrote:
On Wed, May 31, 2017 at 01:30:59PM -0400, Rik van Riel wrote:
> On Wed, 2017-05-31 at 21:37 +0800, Yubin Ruan wrote:
> > I notice that there is a
> > unsigned long i_ino;
> > in definition of `struct inode' , which is the virtual filesystem
> > inode.
> > Does that mean "inode number" and is it used for indexing in the
> > system-wide
> > inode table?
> > If that is the case, would that limit the number of open file in
> > Linux?
> Those numbers are unrelated.
> The i_ino number is the inode number within each
> filesystem, and different filesystems can have
> inodes with the same inode numbers.
Regarding to inode number, I notice that nearly every filesystem has tree
representation of the inode number:
1. on-disk inode number
2. in-memory inode number
3. VFS inode number
How are these related? I mean, if they are all the same, then if filesystem
and filesystem B both have some identical inode number, the VFS inode
Why does it matter ? You don't access inode numbers directly. It always
accessed through a path and that uniquely identifies the inode number based
on the mounted filesystem. Generally clients like nfs use a file handle
which has the filesystem id embedded in it.
> File descriptors (open files) point to a struct inode
> somewhere in memory. The same file can be opened many
> times (all programs opening libc.so). Many files will
> not be opened by any program at all.
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kernelnewbies