The Evolution of Stupidity: File Systems
enterprisestorageforum.com
The Evolution of Stupidity: File Systems
1–10 of 27 posts
Re: The Evolution of Stupidity: File Systems
#2I'd hardly call people who design file systems stupid.
I don't expect them to be psychic, or know everything. I don't even expect them to be the most knowledgeable person in their field. They're just human.
Calling them stupid because you saw something they didn't isn't just rude, it's ridiculous.
Re: The Evolution of Stupidity: File Systems
#3I'm fine with some of the criticisms but using XFS as the posterchild example of a free file system done 'right' is a bit much. XFS has absolutely terrible performance for lots of use cases (deletions, for instance).
What the author also fails to understand - apparently - is that the problems plaguing the storage industry are perennial, they will never be resolved. We will always yearn for more storage that is more reliable at a lower price-point, no matter how good our current technology is.
Re: The Evolution of Stupidity: File Systems
#4It's not a very good article. It's rambling, almost incoherent.
Re: The Evolution of Stupidity: File Systems
#5A linkbait headline that makes the writer seem like the one that is stupid.
If anything he seems to be saying that old known mistakes don't get fixed as we don't learn from the past. This is not evolution but it is an example of the widescale misunderstanding of that word that seems to be common in some parts of the world, it is in fact the exact opposite.
Re: The Evolution of Stupidity: File Systems
#6I'm fine with some of the criticisms but using XFS as the posterchild example of a free file system done 'right' is a bit much. XFS has absolutely terrible performance for lots of use cases (deletions, for instance). What the author also fails to understand - apparently - is that the problems plaguing the storage industry are perennial, they will never be resolved. We will always yearn for more storage that is more r…
> XFS has absolutely terrible performance for lots of use cases (deletions, for instance).
Depends /heavily/ on hardware. XFS evolved on high-end machines, and performs awesomely when you have:
* EITHER large write cache (write cache size >> journal size), think `decent RAID controller',
* OR at least put the journal is on a separate harddrive -- which is very real on average workstation.
Been there, done that, the difference is astonishing.
It boils down to specific media access patterns: XFS uses mixed physical/logical journaling; some operations cause a lot of `physical' (i.e., low-level) representation of directory and file metadata to be written to the journal.
Having harddrive's heads fly back-and-forth between different areas (journal vs. metadata) is a sure recipe for abysmal performance. On the other hand, if you have large write cache to handle journal, or at least employ separate harddrive head to serve journal, directory and file metadata has pretty good locality (thanks to very smart allocator) and the other head doesn't have to move too much.
EDIT:
it's worth noting XFS handles large (multi-gigabyte) files very well, as compared to other filesystems. Both r/w access and creation/removal is fast, on any hardware. This is XFS's original and primary use case: handling large multimedia and scientific datasets.
Want to keep countless virtual machine images? XFS is the way to go, especially thanks to smart allocator which lessens fragmentation as compared to competing filesystems.
tl;dr: XFS is optimized for handling large files. With the right setup -- possible on mid-end hardware -- it also handles numerous small files (say, linux-kernel-size projects) very well.
Re: The Evolution of Stupidity: File Systems
#7The article talks about repeating mistakes, and descends into the world of file systems, but I didn't quite understand what the problem is that is repeated there.
Anybody care to explain?
(FWIW my impression is that there's lots of reinventing going on in the open source FS development; everybody wants to reinvent the cool features from ZFS, but with improved performance or a slightly different architecture, and they all seem to be eager to learn from their own and other people's mistakes).
Re: The Evolution of Stupidity: File Systems
#8I'm fine with some of the criticisms but using XFS as the posterchild example of a free file system done 'right' is a bit much. XFS has absolutely terrible performance for lots of use cases (deletions, for instance). What the author also fails to understand - apparently - is that the problems plaguing the storage industry are perennial, they will never be resolved. We will always yearn for more storage that is more r…
> XFS has absolutely terrible performance for lots of use cases (deletions, for instance). Depends /heavily/ on hardware. XFS evolved on high-end machines, and performs awesomely when you have: * EITHER large write cache (write cache size >> journal size), think `decent RAID controller', * OR at least put the journal is on a separate harddrive -- which is very real on average workstation. Been there, done that, the d…
Yes, large files are fine.
But contrary to your claim many (10's or 100's of millions) of small files and performance is terrible, orders of magnitudes slower than vanilla ext3.
I don't consider the linux kernel to be 'many' files.
Re: The Evolution of Stupidity: File Systems
#9Re: The Evolution of Stupidity: File Systems
#10I'm fine with some of the criticisms but using XFS as the posterchild example of a free file system done 'right' is a bit much. XFS has absolutely terrible performance for lots of use cases (deletions, for instance). What the author also fails to understand - apparently - is that the problems plaguing the storage industry are perennial, they will never be resolved. We will always yearn for more storage that is more r…
> XFS has absolutely terrible performance for lots of use cases (deletions, for instance). Depends /heavily/ on hardware. XFS evolved on high-end machines, and performs awesomely when you have: * EITHER large write cache (write cache size >> journal size), think `decent RAID controller', * OR at least put the journal is on a separate harddrive -- which is very real on average workstation. Been there, done that, the d…
> Having harddrive's heads fly back-and-forth between different areas (journal vs. metadata) is a sure recipe for abysmal performance.
I wonder how XFS performs on SSD, where head transit is not an issue.