Alright, I give up. What does the "i" in "inode" stand for?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Rob Landley
I've been sitting on this question for years, hoping I'd come across the answer, and I STILL don't know what the "i" is short for. Somebody here has got to know this. :)
Boy, how newbie can you get? Fortunately, you've got lots of people setting you straight, and they've given you all those different answers to choose from! ;)
Quoted 4 lines
Another question I'm unclear about is "does every userspace-visible memory allocation have an inode"? Loaded programs are basically mmaped files, and shared memory is now its own filesystem out of which you mmap stuff. But I don't know about a process's stack and heap.
I'd say a mapping "has an inode" if its associated "vm_area_struct" has a non-NULL "->vm_file" (in which case the inode number is stored in "->vm_file->f_dentry->d_inode->i_ino"). By this standard, it's pretty easy to see what parts of a process's address space have an inode. Just "cat /proc/nnn/maps". Each map line will have an inode number in the fifth column or zero if there's no associated inode.
In general, executable text (including shared libraries) and other pages mmapped from real files have inodes. Pages mmapped anonymously don't---if they're private---or do---if they're shared. In the latter case, they have a nameless (i.e., unlinked) inode in the shmfs though its name shows up as "/dev/zero" in "/proc/nnn/maps". Both System V and POSIX shared memory have inodes in shmfs, I believe. Pages allocated with brk/sbrk (including heap for C programs) don't have an inode.
Mmapping "/dev/zero" is a special case. Private (or read-only) maps of "/dev/zero" will be associated with "/dev/zero"'s inode. Make a shared, writable map of "/dev/zero", and it acts like a shared anonymous page: it's associated with an unlinked inode in shmfs, but its name shows up as "/dev/zero" in "/proc/nnn/maps".
Mmapping other devices could do anything... By default, the maps stay associated with the device inode but could be changed by the device code at its whim.
Quoted 4 lines
Then earlier today I wander across kerneltrap's interview with Larry McVoy, who espouses the viewpoint that Linux VM design should store statistics in inodes rather than worrying so much about individual pages, and I get confused again.
Well, if I recall correclty, Larry made it clear in that interview that he wasn't 100% sure how the Linux MM was doing things right now, and he certainly wasn't claiming his scheme would plug right in. If his scheme were to be adopted, presumably we would want to introduce inodes associated with private, anonymous pages (including brk/sbrk pages).
Signature · 1 line
Kevin Buhr <[email protected]>