Is vnode number also limit system-wide number of open file?

[Manish Katiyar]

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' [1], 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
A
and filesystem B both have some identical inode number, the VFS inode
numbers
will conflict.



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.


Yubin

> 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
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170531/8741957f/attachment.html