File System Design part 1, XFS

rchapman writes "Generally, file systems are not considered "sexy." When a young programmer wants to do something really cool, his or her first thought is generally not "Dude, two words... File System." However, I am what is politely termed "different." I find file systems very interesting and they have seldom been more so than they are right now. Hans Reiser is working on getting Reiser4 integrated into the Linux kernel, the BSD's are working on getting a journaled file system together, and Sun Microsystems just recently released a beta of ZFS into OpenSolaris. "

Re:division

[Anonymous Coward]

RAID is best done at a separate LVM layer so that any FS can be built on top of it. I don't see much advantage in building this into the FS. What advantage is there in putting metadata on separate volumes? You need less reliability or something?

obligatory

[DrSkwid]

If you like on disk file systems you should read Venti: a new approach to archival storage [bell-labs.com].

Plan9 [bell-labs.com]'s primary on-disk storage is Fossil [wikipedia.org], which runs in user mode. (Plan9 doesn't have a super user)

You can run arbitrary programs in Plan9 that present a file/folder directory structure by using the common 9P protocol. All devices look like files and folders and can be manipulated like any other, even at the permission level.

For instance, I have an image mounter that takes a tga file and presents 1 folder containing 4 files, red, green, blue and alpha.
I can then use any tool I like to manipulate those files using the file semantics we are all familiar with. I even have a flag that mounts the files as textual rather than binary, i.e :
00 00 ff ff
00 00 ff ff
ff ff 00 00
ff ff 00 00

and I can do image processing with awk !

I concur, Mod Parent Up

[NixLuver]

from TFA:
"There is a minimum size you can write to or read from the disc. This minimum size is called a "sector," and is usually around 512k. So, unless you really like 512k files, it is very likely that you will end up either wasting space or cutting off the end of the file if your file system doesn't deal with this."

This is clearly not a typo - which is what I was certain I would find when I did RTFA. This guy has a basic, fundamental flaw in his understanding of the very thing he's writing an article about. This is a non-starter, IMO. Combine that with poor sentence structure and bad scansion ... I mean:

"Note: My ibook has a "30 gig" drive. This is bullshit and I'll tell you why: Drives are defined by the binary definition of mega, kilo and giga. For example, a kilobyte is not 1000 bytes, but actually 1024 bytes. However, your HD manufacturer uses the metric definitions, even up to gigabytes. Now I can see you thinking..."But Wait Mr. Mad Penguin Person...Thats patently ridiculous and means they are lying on the box." Yah... "

If I'd written something like that, I'd delete it right away and start from scratch.

This Kind Of Article

[Anonymous Coward]

What compels people to make the leap from "I've grasped the basics of a large and complex field" to "I think I'll write an article about it for the Slashdot crowd" via "I'm sure it doesn't matter that I'm not a good writer" and "I think I'll go with a self-satisfied tone"?

Author doesn't mention his newbie status

[Anonymous Coward]

From the article:
Small difference there. It is also a very fast file system, allowing reads of up to 7 GB/sec.

An assumption which could only be made by a newbie. Maximum throughput of a filesystem is not filesystem architecture dependent, but hardware dependent.
I could give you 7GB/sec out of a FAT drive, given the proper hardware.
Several other quotes suggest a bit of 'newbieness' like "B+trees are insanely complex".
The concept was designed by a human, therefor it is clearly understandable by a human. It's not say, some potentially impossible-for-humans-to-really-comprehend law of nature.
The author should just acknowledge that he or she does not know enough about B+trees, or does not know them well enough to illuminate the subject sufficiently.
There's nothing wrong with that, but trying to scare people off of them just because he or she doesn't understand them well enough is damaging to potential readers.

I want to postscript this with an evaluation that the article is not bad. If those things are changed, I would even say it is good.

-fooburger

Re:Blatant error

[Anonymous Coward]

There are lots of other errors as well. For instance he asserts that the inode contains the filename (they don't). Other things are unclear. He refers to UFS and says it scales to around disks of 1TB, but does not define what he means by UFS (as opposed to FFS). He shows a considerable bias to PC hardware by refering to MBR's. He seems to think that taking something out of a B+-tree is faster than removing something from the front of a linked list. I have no idea why he thinks that Unix at Berkeley was "stillborn".

less reliability?

[newr00tic]

No, I was thinking more along the lines of when(/if) META-data becomes big, and you'd get further throughtput by having it on its own drives, so as to speed things up.

By all the three examples I provided, I tried to "account" for both speed and reliability, even though it's only a vague theory..

--No wonder (_real_)things keep standing still for fscking 10 years at the time, and only Disney features are implemented; people turn down theories just as snappy as they turn down webdesigns (50ms, or whatever)..