Mailinglist Archive: opensuse (626 mails)

< Previous Next >
[opensuse] Hard division inode/data is an anachronism
On 10/11/18 04:10 AM, L A Walsh wrote:
    However, the MS case, inodes are kept together in 1 area
and content in another, though in a way that is true for linux as well.

Well, yes ... and no.

Certainly in the days of the UNIX V6 and V7 file system that was the case; and
as I keep complaining, it required preallocation and you could run out of one
before the other.

The Berkeley Fast File System still had this, but rather than ALL the inodes at
the start of the disk, it arraigned them in groups in batches across the disk,
but there was still the HARD separation between inodes and data.

In theory, a B-tree system can get around that. The ReiserFS certainly does,

The ext4FS doesn't; it still has a 'hard divide', the need for preallocation.
However it arranges the inodes and the data on b-tree lists, but separate ones.
It makes access faster, I suppose.

The BtrFS follows the idea of ReiserFS in that there is no division in function
inode vs data. It is just blocks allocated off the b-tree list on demand.

To the best of my knowledge the IBM derived JFS is like that as well; or at
least it acts that way as far as I can tell, I've not looked at the source.

I'm led to believe that XFS is also this way, that space is in a b-tree and
blocks are handed out on demand and there is no pre-allocation as to inode or
data. My experience with XFS is limited, but everything I've read makes it
clear that there is a LOT that can be tuned about the size, structure and
allocation of the inodes, never mind how XFS interacts with RAID. Some people
seem to like fiddling with all this tuning. I don't.

So, yes you can configure your file system with the archaic V7 style FS, it's
called "sysv", but I can't see a mkfs or a fsck for it.

The "Berkeley Fast File System" has seen incarnations for SUN, Next, the Amiga
and for BSD,
but I don't know about Linux. There is a 'ufs' driver, but see the same
apprehensions about mkfs and fsck as for 'sysv'.
Linux includes a UFS implementation for binary compatibility at the read level
with other Unixes, but since there is no standard implementation for the vendor
extensions to UFS, Linux does not have full support for writing to UFS. The
native Linux ext2 filesystem was inspired by UFS1 but does not support fragments
and there are no plans to implement soft updates.[citation needed] (In some
4.4BSD-derived systems, the UFS layer can use an ext2 layer as a container
layer, just as it can use FFS and LFS.)

Personally I view the hard division of inode space and data space on these file
systems to be an anachronism and a limitation that faster machines, larger
address spaces and particularly good b-tree code has made irrelevant.

In addition, given ReiserFS, XFS, BtrFS and JFS and their use of true b-tree
pools that make the preallocation of the number of inodes a mkfs issue, ext4 is
on a weak footing in this regard; only its excellent performance justifies its
use. If there is an ext5 that breaks away from this preallocation model, then
it is going to be a horrendous piece of code to do that AND maintain backward
compatibility. I suggest using one of ReiserFS, XFS, BtrFS or JFS.

“Let us not, in the pride of our superior knowledge, turn with contempt from the
follies of our predecessors. The study of the errors into which great minds have
fallen in the pursuit of truth can never be uninstructive. As the man looks back
to the days of his childhood and his youth, and recalls to his mind the strange
notions and false opinions that swayed his actions at the time, that he may
wonder at them; so should society, for its edification, look back to the
opinions which governed ages that fled.”
― Charles MacKay, Extraordinary Popular Delusions and the Madness of Crowds

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

< Previous Next >
Follow Ups