OSNews

Have you removed BFS? Have you removed BeOS? BeOS is not a $ machine? I suppose!

Excuse me. I'm very sorry! I want BeOS R6. I want more BeOS news. I'm tired and I attend Palm reply.

I have BeOS and BFS. I did not removed anything. But Dominic Giampaolo who created BFS is for holidays in Europe *for six months* (he took a long break recently)! So I could not get an interview from Dominic right now. But I have this in my to-do list. And when this happens, expect some real life pictures with Dominic without his long hair (I know Dominic personally, so I guess we can arrange to get some pics). :-)

I thought Dominic Giampalo worked for Google now. Is he still doing anything with BFS?

Dominic left Be after their focus shift last year. He worked a bit for Google, but now he is working for QNX. He does not doing anything with BFS anymore, but: 1. He is the creator of BFS 2. No one else did anything with BFS after he left anyway.

The most useful feature that HFS+ has is FileIDs. I don't know of any other filesystem which supports them.

Thanks for those interviews, Eugenia - very cool idea to gather these minds together on one page. Shame Dominic couldn't be here for this. I thought it was interesting that while all of these filesystems are evolving, none of them seem to really have a good grasp on exactly how amazing Be's meta-data and live queries really are. Seems weird to me... using the filesystem as a virtual database is to this day one of the last remaining really amazing things about BeOS, and is something that benefits the end user so directly. Every day in every way. Journaling is nice, but I really have to wonder why they're placing the priority on that rather than on meta data and live queries. Those two things really changed the way I thought about computers and computing. Now that I'm starting to sniff around in Linux more (and mostly hating it), I find that the BFS' special properties are some of the things I miss the most. Looks like it's going to be a while before Linux has anything approaching the coolness of Be's file system. Sigh...

Great interview Eugenia. Now what would really be cool is a benchmark of various file systems (NTFS, HFS+, ext2, BeFS, XFS etc). One thing that I've noticed on my x86BeBox (perception is a non accurate science)is that Journalling takes a performance hit when compiling large projects with hundreds of small files. The overhead of an extra write (to the journal) means that compiles take longer than on non-journalled systems. Noticably longer. Now if we can only get Dominic to visit OpenBeOS . . . We'll even let him program nude ;-)

All along I had been told that the Linux JFS was an AIX port. Now that is really bad having used JFS since OS/2 WSeB was in beta until last year I can tell you it is really bad. Their optimizer takes way too long and the manual checkdisk forget it, can take hours on a 10 gig. If you ever get the message "cannot find M:" I pray you don't have a gun nearby.

Excellent article. Thanks very much!

Very nice article.

Thank you for the great read! An idea for another article with a different twist would be to bounce the comments between the interviewed people, just like a panel. It would be really interesting to hear what they say about each other's thoughts!

Here is an interesting URL, I haven't tested it but it seems interesting. http://hp.vector.co.jp/authors/VA008030/bfs/index.html --- paul Balez EPITA student "C++ needs an AOP port and compiler"

what about Kurt and AFS, I though that did all the groovy stuff too?

5

Maybe my question is a bit ( or a lot ) naïve, but what about ext3 ? Not a word in the whole article, except a short one by Hans Reiser, and the "unamed mention", which seems to come more from the cold war between Suse and Red Hat than from a technically argued discussion... About the benchmark, I thought (still naïve, no ?) that a reliable benchmark had to come from a non-implied third-party. This doesn't mean to be a troll start or a sterile flame war, but I'm still searching for an objective comparison, to make a choice as much judicious as possible for production boxes. So what ?

Great interview! It was nice having 3 diffrent pepole answer the questions about there FS... very nice article!

IIRC, Kurt's AFS is mostly based on BFS, he got most of the code from "Practical File System Design with the Be File System" (written by Dominic Giampaolo)...

Thank you for that interview, I hope this makes those excellent file systems more popular. I can't understand why everyone still's using GNU/Linux with ext2. To Scott Hacker: As much as I appreciate metadata, I think journaling is much more important. The most valuable thing for software should be the user's data and software should do as much as possible to keep the user's data as safe as possible.

To those people who suggest that metadata and live queries aren't as important as journaling, I tend to disagree. Both are of equal importance. Journaling is absolutely required to keep the users data safe. Yes, this is very important. But has anyone here actually tried the BFS? I mean, its amazing Basically, you can do file searches at almost the same speed as performing a 'locate' command in Linux. And no 'updatedb' is required! The 'find' command is basically made obsolete. And I tried this a few years ago on a slow 4800 RPM drive. I'd love to see what it could do on the 7200RPM IBM drive I have now

Well, really interesting writeup. BTW, NTFS is hardly a journaled filesystem, no matter how much Microsoft would want you to think so. Actually, sometimes NTFS volumes are absolutely un-recoverable (that's when we wished we used FAT instead..). In my opinion, the most advanced filesystems overall are BFS and Netware Storage Services. NSS is not only a filesystem and a database, it's much more, and it's extensible. But for a non-server computer, BFS is ideal. It has the perfect blend of ournaling, 64-bit-ness and metadata capability.

The UMN/sistina GPLed GFS is a journalling filesystem that runs on regular old linux systems. With additional help, it also runs as a filesystem shared between multiple systems, but that isn't necessary. It seems to be left out of all these FS comparisons unfairly, IMO. -dB

..that Microsoft stopped work on their WebSystemFS (used in Exchange 2000), to merge the codebase with MSSQL and NTFS? I think Microsoft is actively adding the "Live query" and meta-data to NTFS (with other stuff too).

Actually, you'll probably find that with modern hard drives, the time in which you can search the entire FS and simply examine each file is not very long anymore. That is why you make a "noindex" bfs volume for holding, say, your source trees. If I were to design a new filesystem today, I would leave _out_ indexing since that means you incur quite an overhead for day-to-day operations (and an increase in code complexity, of course) to gain "quick finding of files". Someone with a modern disk and, say, ext2fs, how long does it take to run a find command? (Genuine question, not a troll.)

Good comments, Sander, but you know that "find" is a poor substitute for the power of real BFS queries, where the query parameter set is infinitely flexible. Find can only find filenames... which is pretty limiting in comparison.

I've been using XFS at home on my RedHat 7.1 systems since version 1.0. Apart from a minor error with GCC 2.96 (or whatever weird GCC RedHat ship with) - having to force a kernel recompile of 2.4.5 to use kgcc - it's been running quite merrily. I've not noticed any lack of performance although deleting huge amounts of files can be a little tedious; this might sound weird for a home machine but I like to tinker with mozilla and kernels so it's quite common for me to have masses of files suddenly deleted after I've decided that I've finished with the sources. What I have noticed is that my XFS systems run as quickly as my EXT2 systems on the same machine. Furthermore, on a machine where I had XFS and reiserfs (XFS V1.0/RedHat SGI Compiled Kernel and RedHat 7.1's RedHat Compiled Kernel + reiserfs), I couldn't honestly tell the difference. DSL

The fact that "find" only lets you search on filenames is not a limitation of the algorithm used per se (i.e. sniffing all files as opposed to looking something up in an index), but because of Unix traditionally doesn't use attributes. "Find" does let you search based on the limited "attributes" that Unix knows, i.e. look for directories, or for executable files, or for files modified after a certain date. In fact, BeOS's queries only work if there is at least one indexed attribute in there; if you want to look for a certain non-indexed attribute you have to resort to a hack like (name=="*" && myattr=="foo"). Also, with "my" version of the FS and query stuff, you could easily look for "all files named *foo* in directory /only/this/dir", which is hard to do on the BeOS. On a file system that was optimized for good streaming performance at the expense of the time it takes to traverse directories and find files (purely hypothetical optimization), indices of course would make lots of sense. All I'm saying is that in the OS that I would write, I wouldn't bother with indices and see if I really miss them.

Re: NTFS The Encript & Compress options mean I like it lots. Does anyone know if any of the others support it?

I saw someone here claiming that Warp Server for eBusiness was in beta last year. Not true. If i look on the timestamps on the GA version of WSeB files it says 990416. While the preview (or called by som, beta) says 981012. The first generations of JFS had some bugs but things has happends since 1999, the latest JFS realese (that i have used) from 010622 has so far been flawless. On accidantly shutdown servers, chkdsk on 10GB JFS volumes takes up to 10 minutes, while chkdsk on 1GB HPFS volumes can take 30 minutes (both on Ultra160). I have, so far, not lost any file on JFS. On thing that is bad on JFS for OS/2 is that it is not an bootable filesystem. You need to put your bootpartitiation on something else, like HPFS for OS/2. Now waiting for the client eComStation www.ecomstation.com who also has JFS.