6

It is my understanding that Linux locates a file on disk using the inode table. Does the Linux file system hold the inode table in memory? Would this be the same regardless of ext2, ext3 or ext4?

By any chance is anyone aware of a good reference that describes this?

RG_Simpleton
  • 61

3 Answers3

3

This has been covered here already: Is the file table in the filesystem or in memory?

That seems to be pretty thorough. But it is still a good question. As you can see, the question is actually more granular than your question suggests.

http://140.120.7.21/LinuxKernel/LinuxKernel/node17.html that's a more technical explanation that seems to cover the same question, with the same answer, there are inode tables in memory and on disk, different types, if I read it right. That's from 2008 but I suspect that at least for ext file systems, not much has changed, though I don't know that for certain.

The old kernel explanation is actually quite good:

An ordinary file is just a sequence of data bytes stored in some physical device without any name attached to it. The administrative information of this file, such as owner, permissions, size, times, etc., is stored in the inode structure of the file. All of the file system's inodes are collected together to form an inode table. Each file system occupies a logical disk. Starting from the $2^{nd}$ block of a logical disk, the kernel stores the inode table of the file system in a consecutive disk blocks. Each inode, an entry in the inode table, is a data structure which the system uses to store the following information about a file:

....

Finally, there is one more inode structure defined in the Linux source tree (include/linux/fs.h). This is the In-Core inode, i.e. the inode structure loaded in the memory. When loading this In-Core inode, the relative disk inode information is filled in its relative fields.

Lizardx
  • 3,058
  • 17
  • 18
  • Thank you. I had read that, and it did seem helpful, but that answer does not explain (and as you point out my question lacks the granularity that would specify this) what the relationship between the in-memory inode table and the on disk inode table. Are they related, is one a subset of the next? And, what would be a good reference describing all this? (Is there an Inode Tables for Dummies book? :) – RG_Simpleton Sep 18 '17 at 04:07
  • I'm assuming any decent linux kernel book, ideally from O'Reilly, would probably explain this more in depth, if in depth is what you need. I found that reading both the long SE answer, and the kernel answer, it kind of gave a sense for it. But if you're asking in terms of working with this programmatically, you'd want to get a real reference in my opinion, a book, that is. I doubt there is a dummies book for kernel stuff like this, it's not a dummy topic, lol, it's complicated and difficult to explain in shorter words than the logic requires. – Lizardx Sep 18 '17 at 04:14
  • Thank you Lizardx, much appreciate. I agree, and your answers are very helpful. I was only being a little lighthearted when I asked about the for Dummies book. Yes, a good O'Reilly book is probably in order.

    Thank you again.

     – RG_Simpleton Sep 18 '17 at 04:16
  • It's kind of like trying to really understand how the kernel handles pages, memory, etc, it's not really easily explanable I've found. But I thought the SE answer was an excellent attempt at trying, for example, noting that of course, this being a nix, stdin, stdout, are files, which have inodes, which exist in memory. And when you open a file, that creates an inode table in memory. – Lizardx Sep 18 '17 at 04:16
  • thanks for asking a good question, I don't dip into this stuff too deeply often, but it's nice to do it once in a while. But you'll have to probably accept that if you are serious about understanding this stuff, you're probably not a dummy, lol. – Lizardx Sep 18 '17 at 04:17
3

Linux (and actually any other Unix) doesn't need inode to locate file on disk, lookup operation only needs directory entries (dentry), i.e. for the path is /foo/bar, lookup routine will need to access dentry "bar" located in directory "foo".

There is a cross-filesystem layer in Linux kernel which caches directory entries which is called directory entry cache or dcache for short. However, it keeps pointers to inode objects as well. It is described in kernel doc filesystems/vfs.txt:

The VFS implements the open(2), stat(2), chmod(2), and similar system calls. The pathname argument that is passed to them is used by the VFS to search through the directory entry cache (also known as the dentry cache or dcache). This provides a very fast look-up mechanism to translate a pathname (filename) into a specific dentry. Dentries live in RAM and are never saved to disc: they exist only for performance.

The dentry cache is meant to be a view into your entire filespace. As most computers cannot fit all dentries in the RAM at the same time, some bits of the cache are missing. In order to resolve your pathname into a dentry, the VFS may have to resort to creating dentries along the way, and then loading the inode. This is done by looking up the inode.

myaut
  • 1,431
0

In general, Linux only loads an inode into memory when the file is opened. The data may persist in updated form in memory for some time after a file is closed before it is flushed to disk (via caching logic) or marked disused.

It is frequent usage pattern of filesystems for some files to be repeatedly opened and closed. There is efficiency to be gained by not re-reading the inode in subsequent reopens.

The authoritative reference is the Linux kernel source code. The source/Documentation directory in the source tree often has details like you are looking for, but may be not completely updated to match the source.

wallyk
  • 248