On 2018-09-11 4:44 p.m., Carlos E. R. wrote:
Ah, yes, but I understand on XFS inodes are dynamic, not fixed at format time.
Once I run a test creating many thousands of small files. btrfs was sluggish and finally crashed, ext4 coped till inodes spent, xfs coped well (till disk full of new inodes, IIRC), and reiserfs wanted more.
Yes, this is the point I was trying to make about ext4 still being stuck in the old old model of resource preallocation. A REAL Btree FS allocates resources dynamically ... all resources. Ext4 just uses Btree mechanisms to pool free blocks rather then the first-in-last-out queue model that the old UNIX V5,V6,V7 used and that was later inherited down the line. ReiserFS is remarkably efficient about packing all the small files it can. In a world where you have lots of smell scripts, that's wonderful. And it doens't do that at the cost of larger files. Too many systems, other FS, trade off one thing for another. You optimise for small files at the cost of large ones. The downside of ReiserFS is threading. Look at the man pages for ext4, ReiserFS, JFS, and XFS and compare the number of tuning opinions you can play with to 'optimise' the FS for one thing or another, or fail to take advantage of some feature. I mean, consider this from the ext4 man page: dir_nlink Normally, ext4 allows an inode to have no more than 65,000 hard links. If you have that many files in a directory then I think you have some design problem in your application. -- 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org