On 08/21/2014 08:33 AM, Carlos E. R. wrote:
On 2014-08-21 14:02, Anton Aylward wrote:
On 08/20/2014 10:16 PM, Carlos E. R. wrote:
Ah, but you forget the huge number of inodes used :-P
Not an issue with the b-tree-like FS such as ReiserFS, XFS and BtrFS.
Yes, it is is an issue on btrfs, as I demonstrated it with a test that I published here. The filesystem crashes completely if you create "too many" small files, and speed diminishes hugely before that. There is an unsolved bugzilla on it.
Date on that? Details?
XFS adjusts the equivalent of inodes dynamically, it adapts, but nevertheless, it has a limit. The recommendation is to tune the filesytem, on creation time, for many small files.
ext2/3/4 has a fixed number of inodes, but it can also be tuned for a large number of small files.
Reiserfs is the only filesystem that has no issues with the situation, and is way faster than the rest (in this situation). But development is stuck, and it scales badly (only one thread is used for all the reiserfs partitions you have, regardless of the number of cores you have). It is possible that it disappears from the distribution not far in the future - in 13.1 you can not create a reiserfs in YaST, for instance, support has already been removed there.
That's a good summary. Many feel that BtrFS is going to replace ReiseFS and give their rationalization, but as you point out its not quite there yet. The standardizing/default of BtrFS and the removal or ReiserFS are premature, and I say that as someone who supports BtrFS. My own experimentation shows that BtrFS works best on huge file systems that have no physical partitioning. That is no separate /home/ usr, /var and so on. It optimizes and balances the whole damn lot. I suspect, or is that fear, that the optimization of BtrFS will eventually do this: Oh look! That sector of that file and this sector of this other file are the same byte-for-byte so lets link then both to single copy and tag it for COW. And so all of the /usr/bin and /usr/lib will be optimized to hell. No, really, with all of a 4T drive as a single BtrFS what's the odds that there are two files with a sector the same? I run FSLint and I find I have quite a number of duplicate files at the size&md5 level and sometimes even the name is the same or similar. LOTS of them. More than the space wasted by maidir messages not filling all of 4K partitions, which is a non issue on my ReiserFS where INBOX lives because of the way, as you say, Carlos, that ReiserFS deals with inodes and how it packs small chunks. Aren't Btrree's wonderful? Sometimes the way BtrFS is developing scares me.
Nor is the 'growth' of the size of the directory & compacting it nor, if you set up the options to start with, sorting huge directories.
The problem with ext-series is that you have to know about it at Mkfs time. Yast and Installer aren't great about advising you on this issue and the values in mke2fs.conf are someone else's idea of what you should use; not as flexible as ReiserFS.
It is an issue in the sense that it impacts performance a lot. You only need to run tests on large mail folders using several formats, and compare. Some workloads run faster on maildir, and some on mbox.
"Context is Everything". Which is why I use both maildir and mbox .... in different contexts. -- 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