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

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

[Okash Khawaja]

> On 31 May 2017, at 14:37, Yubin Ruan <ablacktshirt@gmail.com> 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?
> 
> I know there *is* such a limit, and superusers can adjust that by
> /proc/sys/fs/file-max. Currently I cannot raise that to too high, otherwise
> the system would crash, which I think is because I have limited memory. But,
> the point is, if I have lots of memory in my machine (say hunderds of
> Gigabytes), would the number of open file system-wide limited by the `i_ino'
> above? Since its type is "unsigned long", I guess I can only open
> 2^(sizeof(unsigned long)) file simultaneously? 

2^(8*sizeof(unsigned long))

Which is big. Is there some use case for very large number of files?

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

[Yubin Ruan]

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?

I know there *is* such a limit, and superusers can adjust that by
/proc/sys/fs/file-max. Currently I cannot raise that to too high, otherwise
the system would crash, which I think is because I have limited memory. But,
the point is, if I have lots of memory in my machine (say hunderds of
Gigabytes), would the number of open file system-wide limited by the `i_ino'
above? Since its type is "unsigned long", I guess I can only open
2^(sizeof(unsigned long)) file simultaneously? 

--
Yubin


[1]: http://elixir.free-electrons.com/linux/latest/source/include/linux/fs.h#L575

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

[Rik van Riel]

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.

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.

-- 
All Rights Reversed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170531/e88422ec/attachment.bin 

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

[Yubin Ruan]

On Wed, May 31, 2017 at 08:34:09AM +0100, Okash Khawaja wrote:
> 
> 
> > On 31 May 2017, at 14:37, Yubin Ruan <ablacktshirt@gmail.com> 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?
> > 
> > I know there *is* such a limit, and superusers can adjust that by
> > /proc/sys/fs/file-max. Currently I cannot raise that to too high, otherwise
> > the system would crash, which I think is because I have limited memory. But,
> > the point is, if I have lots of memory in my machine (say hunderds of
> > Gigabytes), would the number of open file system-wide limited by the `i_ino'
> > above? Since its type is "unsigned long", I guess I can only open
> > 2^(sizeof(unsigned long)) file simultaneously? 
> 
> 2^(8*sizeof(unsigned long))
 
 good catch.

> Which is big. Is there some use case for very large number of files?

No, I just wonder whether this is the limit...

--
Yubin

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

[valdis.kletnieks at vt.edu]

On Thu, 01 Jun 2017 17:15:29 +0800, Yubin Ruan said:

> 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.

What's tracked is the pair (filesystem, inode).  So inode 3945 on /usr
is different from inode 3945 on /home.  (Strictly speaking, it tracks the
major,minor number for the device that has the filesystem on it - so if /usr is
on /dev/sda3, and /dev/sda3 looks like:

ls -l /dev/sda3
brw-rw----. 1 root disk 8, 3 May 31 19:47 /dev/sda3

What's really tracked is ((8,3),3945).  Although many places in the kernel will
equate "a pointer to the in-memory copy of the superblock for the filesystem on
8,3" with the actual major/minor - mostly because if you're looking at the
device node numbers for the filesystem, you're probably going to be needing
that superblock *anyhow*.

Similar games are played for the on-disk and in-memmory inode numbers - as long
as the system keeps track of what the mapping is, there's no need for them
to actually be identical...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170531/6adcc06a/attachment.bin 

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

[Manish Katiyar]

On May 31, 2017 6:15 PM, "Yubin Ruan" <ablacktshirt@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 

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

[Yubin Ruan]

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.
 
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.