> Content-wise, there wasn't really much there for me.
Yeah, I doubt there was anything in it for anyone interested in filesystems. And seeing XFS is my day job, the mistakes were pretty obvious, too.
One, a b+tree does not make a filesystem.
Two, in all that talk about b+trees in XFS, he made some basic mistakes. There's only one inode b+tree per AG, there's two extent free list b+trees per AG, and the superblock has no b+trees in it at all. And they are used in many other places in XFS as well.
Three, there is so much in XFS that this didn't even mention that it could hardly even be called an overview of XFS, let alone design. I mean, the overview page for the XFS project (http://oss.sgi.com/projects/xfs/) has a more informative description of XFS than this article....
Its all a mess... but setting a DRIVE to not cache is NOT the solution! Its retarded to do so, and all the comments in this thread taling of setting the cache off are foolish.
I call BS here.
When a power failure occurs, even if you are running a journalling filesystem, you _really_, _really_, _really_ care about drive write caching.
If the drive has the journalled data in it's write cache and not on disk at the time of the power failure, you've just corrupted your filesystem because the journal replay will not be correct when you next mount your filesystem. Journalled filesystems rely on the journal being on disk when the I/O completes and not some time after.
Toy (*ATA) use write cache for _performance_ because otherwise they suck really badly. And that results in filesystem corruption on power loss. I've seen the mess it makes far too many times....
Slashdot Mirror
> What was the age and the specs of the SGI being replaced?
Well, RTFA:
"Previously, for almost a decade PAGASA used an SGI Irix supercomputer...."
So they were probably using an O2k. Somebody wake me when there is some real news.....
> Content-wise, there wasn't really much there for me.
Yeah, I doubt there was anything in it for anyone interested in filesystems.
And seeing XFS is my day job, the mistakes were pretty obvious, too.
One, a b+tree does not make a filesystem.
Two, in all that talk about b+trees in XFS, he made some basic mistakes. There's
only one inode b+tree per AG, there's two extent free list b+trees per AG, and
the superblock has no b+trees in it at all. And they are used in many other
places in XFS as well.
Three, there is so much in XFS that this didn't even mention that it could
hardly even be called an overview of XFS, let alone design. I mean, the overview
page for the XFS project (http://oss.sgi.com/projects/xfs/) has a more informative
description of XFS than this article....
I call BS here.
When a power failure occurs, even if you are running a journalling filesystem, you _really_, _really_, _really_ care about drive write caching.
If the drive has the journalled data in it's write cache and not on disk at the time of the power failure, you've just corrupted your filesystem because the journal replay will not be correct when you next mount your filesystem. Journalled filesystems rely on the journal being on disk when the I/O completes and not some time after.
Toy (*ATA) use write cache for _performance_ because otherwise they suck really badly. And that results in filesystem corruption on power loss. I've seen the mess it makes far too many times....