"Linux not suitable for large filesystems"
Dan Kegel
Well, I suppose it's true that ext3 is not so good at 200TB filesystems...
Val Henson certainly said as much in her talk
http://www.archive.org/details/LRL_USA_2008_Storage_for_startups
(same talk where she told everyone to stay far away from
ZFS because it has no fscking repair tool, and few people can
understand the code).
But isn't ext4 better at large filesystems?
http://en.wikipedia.org/wiki/Ext4#Large_filesystem
certainly says it is. I suspect the author hasn't been
paying attention...
So, to make this on-topic, I think it may be time to add
an ext4 test to the zumastor test suite.
- Dan
Daniel Phillips
It's on-topic, no question about that.
Ext4 scaled everything up but in truth really does not address anything
that XFS does not already do better. (Note: the old XFS bugbear, zeroed
files after a crash, is now ancient history.)
To be sure, Ext4 is a great and necessary project, offering backward
compatibility as it does (by breaking the backward compatibility of
Ext3!). I fully intend to contribute to Ext4 when I get time, but Ext4
really is more of the same old same old.
The real I/O problems in Linux are mainly outside the filesystems:
* Dirty page scanning and writeout are frightfully complex and often
exhibit undesirable behavior in corner cases.
* Poor readahead, which is per-file in Linux as opposed to per-volume
in Windows
* Poor swapping. I ran across an article last week that showed that
the "random" replacement strategy beats Linux's swapout algorithm.
* Disk elevator algorithms after being tweaked for many years still
have not solved read starvation issues or introduced badly needed
new functionality like real-time IO. The elevator code has however
become frightfully complex.
* Buffer or page cache block size may not be bigger than a physical
page. (Agh!!!)
* <fill in other major deficiencies here, there are more>
OK, I read the article after writing that list and it mentions a number
of the same issues, good. It specifically mentions breaking 512 KB IOs
into 128 KB IOs, and I know exactly why that happens, it is because of
a suboptimal bio allocation strategy, which in turn is because of the
currently broken Linux approach to resource reservation: bio allocation
uses the costly and sometimes ineffective bio pool strategy, whereas the
memalloc strategy implemented via bio-throttle is actually needed. This
issue is somewhat addressed by my bio allocation patch and can be
completely addressed by a combination of that patch and the bio-throttle
work. I sense an opportunity.
The article hits the big issue squarely:
"the lack of someone to take charge or responsibility"
I see no immediate solution to this, due to kernel politics, entrenched
interests, overcommitted akpm, and endemic "geek bully" behavior that
tends to drive away the people who actually have experience with these
issues. The prognosis: just keep muddling on. Eventually somebody or
some people so capable and with such thick skin and with so much time
available and with such determination as to be able to overcome these
obstacles will set things right. Maybe not before Open Solaris takes
hold and Windows grabs even more of the enterprise and desktop markets
though.
Daniel