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, completely. 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. https://www.kernel.org/doc/Documentation/filesystems/sysv-fs.txt 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'. http://www.cse.unsw.edu.au/~cs9242/02/lectures/09-fs/node4.html https://en.wikipedia.org/wiki/Unix_File_System <quote> 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.) </quote> 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org