Is vnode number also limit system-wide number of open file?
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
Quoted 14 lines · 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?
Quoted 7 lines
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?
Quoted 22 lines · Okash Khawaja
Quoted 14 lines · 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?
Quoted 7 lines
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?
Quoted 1 line
2^(8*sizeof(unsigned long))
good catch.
Quoted 1 line
Which is big. Is there some use case for very large number of files?
No, I just wonder whether this is the limit...
--
Yubin
Quoted 4 lines · Yubin Ruan
I notice that there is a?
????unsigned long i_ino;
Quoted 8 lines
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.
Signature · 8 lines
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
Quoted 11 lines · Rik van Riel
Quoted 10 lines · 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??
Quoted 8 lines
Quoted 2 lines
If that is the case, would that limit the number of open file in Linux?
Those numbers are unrelated.
The
i_inonumber 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
Quoted 4 lines
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.
Quoted 8 lines · Yubin Ruan
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
On May 31, 2017 6:15 PM, "Yubin Ruan" <[email protected]> wrote:
Quoted 11 lines · Rik van Riel
Quoted 10 lines · 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?
Quoted 8 lines
Quoted 2 lines
If that is the case, would that limit the number of open file in Linux?
Those numbers are unrelated.
The
i_inonumber 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
Quoted 4 lines
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