Mailinglist Archive: opensuse (626 mails)

< Previous Next >
Re: [opensuse] Re: wrong topic: Re: Hard division inode/data is an anachronism
On 12/11/18 11:02 AM, Liam Proven wrote:
Many filesystems do not use inodes at all. ReiserFS doesn't.

That's not a correct statement.
What you mean is that if you run 'df -i" on a reiser file system ...

$ mount | grep reiser
/dev/mapper/vgmain-vHome on /home type reiserfs

$ df -i /home
Filesystem Type Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vgmain-vHome reiserfs 0 0 0 - /home

Yes, ReiserFS uses i-nodes, but read what I was saying earlier: ReiserFS does
not have a preallocated amount of inodes as does the V6/V7/SCO/sysv and the
ext2/3/4 file systems do. It allocates inodes *as needed* from the pool of free
blocks on the B-tree list, the same pool that it draws from for data.

Let me make that clear: ReiserFS stores *EVERYTHING*, metadata ("stat items"),
directory entries ("directory items"), inode block lists ("indirect items"), and
tails of files ("direct items") in a single, combined B+ tree.

By contrast, the other file systems I've mentioned make use of a fixed index
principle for finding inodes in a fixed size linear array, hence limiting the
number of files they may contain. In addition, such file systems also store
directories as simple lists of entries, which makes directory lookups and
updates linear time operations and degrades performance on very large
directories. ReiserFS avoids both of these problems due to the inherent nature
of B+tree scalability.

And, as I keep saying, unlike the V6/BV7/SCO/sysv and the ext2/3/4 file systems,
it can never run out of one before the other.

Three is a price for that. Since there is not a known number of i-nodes
preallocated you can't tell what percentage are used. You can't tell how many
you had to start with, and to tell how many you have in use you will need to
traverse the whole file system tree, counting as you go along. So the "du -i"
command is meaningless.

Which does *NOT* mean that ReiserFS does not have the information that makes up
an I-node on the disk associated with the the file; it just doesn't do it the
way other file systems do.
But so what?
Linux doesn't do a lot of things that OS/360. RSTS and others did,

The JFS works differently.
There is a separate, dedicated B+ tree for inodes, and the root of that three
holds information about what is on that tree, indicating how many of its entries
in the i-node are being used and another field describing whether they are leaf
nodes or internal nodes for the B+ tree. The tree terms are rather more
'linear' in nature than with ReiserFS and can be copied more directly into

If there is no i-node then were is the information about file size, ownership
etc held? let's face it, B-tree structures are not like the traditional linear
arrays in which 'older' file systems store their inodes. But we are back to the
Rabbit/smurf issue. If it is not an i-node then how is it storing the (POSIX

- The size of the file in bytes
- Device ID
- User ID of the file
- Group ID of the file
- The file mode that determines the file type and how the owner, group,
and others (world) can access the file
- Additional system and user flags to further protect the file (think: xattr)
- Timestamps
- A link counter that lists how many hard links point to the inode

and of course the essential ...
- Pointers to the disk blocks that store the file’s contents

That it is not stored (on disk* in a predetermined place as as a part of a
linear array does not stop it being an i-node.

Once it is accessed, what is in memory, in the "inode table", however that may
be organized (and I'm not presuming it is a linear array either), then it looks
just like the in-memory inode of any other file system.

You can bet that when a VFAT file system file is accessed it has an in-memory
inode that gets 'mapped' to look like everything else :-) No matter what the
"Block" looks like on disk.

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups