Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolution of Stupidity: File Systems

enterprisestorageforum.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: The Evolution of Stupidity: File Systems

#11

Post by rbanffy »

perlgeek wrote: post #7

The 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…

> everybody wants to reinvent the cool features from ZFS,

Perhaps because ZFS cannot be integrated into Linux due to licensing issues. If Oracle would be generous enough to offer it under a compatible license, I have little doubt it would be very welcome, despite some of its architectural incompatibilities.

Re: The Evolution of Stupidity: File Systems

#13

Post by scott_s »

perlgeek wrote: post #7

The 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…

I had the same question. He has no clear thesis. He never says, "The problem with current filesystems is: ___".

Re: The Evolution of Stupidity: File Systems

#14

Post by notmyname »

0x12 wrote: post #8
dexen wrote: post #6

Earlier quoted context omitted.

> 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.

As we were developing openstack swift, we evaluated many different file systems and settled on xfs because our testing showed it to be faster than other file systems when storing many small files (where "many" is much more than the number of files in the linux kernel).

Unfortunately, I can't find the test results that back up my claim.

Re: The Evolution of Stupidity: File Systems

#15

Post by 0x12 »

notmyname wrote: post #14
0x12 wrote: post #8

Earlier quoted context omitted.

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.

As we were developing openstack swift, we evaluated many different file systems and settled on xfs because our testing showed it to be faster than other file systems when storing many small files (where "many" is much more than the number of files in the linux kernel). Unfortunately, I can't find the test results that back up my claim.

Yes, storing files is fast. We ran similar tests to yours and storing never was the problem, deletion also wasn't a problem as long as the number of files was in the low millions. The problem comes around when you start to delete files once you have 10's of millions of entries.

I helped a customer set up a CDN and this was one of the most painful mistakes I ever made to correct for. It took weeks to migrate all the data to EXT3 filesystems while the system was live. The whole point was to end up with something scaleable, the 'sweep' ran 3 months behind the write so after 90 days, with the filesystems nicely filled to 80% capacity or so we found out that deleting a single file would take an impossibly long time.

In the end we found a manageable workaround, to try to select candidates for deletion on a directory-by-directory basis which improved performance to the point that we could migrate the data but it still was a pretty scary operation.

Re: The Evolution of Stupidity: File Systems

#18

Post by spudlyo »

0x12 wrote: post #3

I'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 gets some things right. As far as I know it's one of the few Linux filesystems that doesn't serialize writes to O_DIRECT opened files, which is why it's very popular for databases.

Re: The Evolution of Stupidity: File Systems

#20

Post by mmatants »

perlgeek wrote: post #7

The 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…

I, for one, thought that he was going to argue against the overall hierarchical FS metaphor. Personally, I wonder what things would be like if the OS provided a key-value store (or some such NoSQL-ish API) as a core service instead.
Post reply on HN