Mailinglist Archive: opensuse (626 mails)

< Previous Next >
[opensuse] It is the information that counts, not its representation on disk.
On 13/11/18 07:37 PM, L A Walsh wrote:

    You miss Liam's point.  The inode was/is something specific in
unix terminology/technology.  It's not a generalizable term for metadata.
Metadata has a soft-edge meaning and isn't a technical data structure.
An inode is. 

No I don't miss his point.

My point is that it is the same information, no matter how it is stored on the
disk, and once it is read in, doing a 'stat()' or 'open()', the representation
in core, in the kernel's i-node table, is the same.

You might as well say the data isn't the same because it is in a B+ tree rather
than an an indexed block where the index is an array in another block.

*It is the information that counts, not its representation on disk.*

Point in case: no matter how the information is represented on the disk,
whatever the file system, as far as the application is concerned the information
is one long continuous array of bytes. Whether it is in 512 bytes blocks on
disk, 1K (as with early BSD and some experimental V7), 4K blocks, stuffed in the
tail end of an inode block, whether it is in an indexed, double indexed or
triple indexed list of blocks, whether it is put together from a B-tree or B+
tree list, is IRRELEVANT.

*It is the information that counts, not its representation on disk.*

And so too with in-odes.


All this came abut because ReiserFS is COMPLETELY B+ Tree based, so there is no
pre-allocation of the number of i-nodes and hence the 'df -i' is meaningless.

As for JFS, while the actual allocation is dynamic off a tree, there is a limit:

<quote src="";>
The entire JFS volume space is subdivided into allocation groups. Each
allocation group contains i-nodes and data blocks. This enables the file system
to store i-nodes and their associated data in physical proximity (HPFS uses a
very similar technique). The allocation group size varies from 8MB to 64MB and
depends on fragment size and number of fragments it contains.
So it is only truly dynamic within an allocation group. Within a group you can
run out of one or the other, just like Ext4. But unlike Ext4, you can move to
another group ...

An i-node is a logical entity that contains information about a file or
directory. .... It should be noted that the number of i-nodes is fixed. It is
determined at file system creation time and depends on fragment size (which is
user selectable). Users could run out of i-nodes, meaning that they would be
unable to create more files even if there was enough free space. In practice
this is extremely rare.

The XFS has a similar 'sort of" preallocation and can run out of inodes because
of the 'allocation group" approach. particularly with a highly fragmented FS.

It comes down to two things:

* are there the resources for that sort of information?

if there is preallocation, ANY kind of preallocation, then that is possible

* it is the information that counts, not how it is stored.

Some file systems use blocking that allows other things to be stored in the
on-disk inode that make up no part of the in-kernel inode table format that is
common to all opened/accessed file. E.g. 'extended attributes' with XFS is they
are small enough. The XFS inode consists of three parts: the inode core, the
data fork, and the optional attribute fork. This is not the "inode traditional
to unix terminology". Is it a files metadata?

What all this comes down to is that not matter how it is stored on disk, what
DOES matter is what gets into the i-node table in the kernel when a file is
accessed. THAT is the common point which defines the only generally accepted
i-node structure.

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 >