On May 31, 2017 6:15 PM, "Yubin Ruan" <ablacktshirt@xxxxxxxxx> wrote:
On Wed, May 31, 2017 at 01:30:59PM -0400, Rik van Riel wrote:Regarding to inode number, I notice that nearly every filesystem has tree
> 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.
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@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/ kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
