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
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?
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
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.
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.
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...
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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (5)
-
Manish Katiyar -
Okash Khawaja -
Rik van Riel -
valdis.kletnieks＠vt.edu -
Yubin Ruan