The BeOS file system, an OS geek retrospective (2018) | Hacker News Reader

The BeOS file system, an OS geek retrospective (2018)

arstechnica.com

69 pointspcr91030319 comments

As always when I see Be file system stuff I point people to the very readable document by its creator:

http://www.nobius.org/dbg/practical-file-system-design.pdf

> I'm not sure. I think it will be a little while yet before we sort out which layer is the right place for all the different parts of the problem of "storage." ZFS has gone down the path of putting everything in the FS. Other folks are putting in a different set of things. It's pretty clear that some of the functionality that existed in BFS does not belong in the FS.

Now that's wisdom.

I do wish he'd gone in to more detail though!

I imagine the extended attrs and db would be amazing for app devs, but probably wouldn't see much use in the real world because it ties your application to the file system. But what else?

Tying your app to the fs isn’t that bad if the fs is flexible and portable enough such as zfs having the ability to use plain files.

Doesn’t seem much worse than tying it to a particular database or API

my first response was 'but filesystems live on the disk' while databases are simply to set up in userspace. but then i realized that with FUSE and filesystem-image files and the right tooling the same flexibility can be achieved, and also, on the other side high performant databases want to live on the raw disk to be in full control of the write process to disk.

what remains is that the difference between a filesystem and a database is the API used to talk to it.

Besides of the FS BeOS had a great iconic UI.

This is 2010, not 2018.

Even tools that collect files and put them in a database like "everything" for windows are extremely helpful. Being able to search and filter all files on all drives in real time is a big game changer.

Has any other filesystem added in i-node arbitrary attribute tags? This would be invaluable for collections of documents, and would make most library managers like calibre or tmm redundant.

Don't all modern filesystems support extended attributes? (i.e. I don't understand what is so different between the BeOS addattr/catattr commands in the article and the standard Linux setfattr/getfattr commands)

The addattr/catattr aren't where the fun is. That's in the indexing, allowing you to treat files with these attributes more like rows in a database. "Efficiently find me all files that have a 'genre' field set to 'bluegrass', regardless of extension" is something you can do for instance, at the filesystem level.

Sure, but the question was about whether any filesystems allow you to store the attributes.

Storing and retrieving the attributes is the hard part that requires filesystem support, I think generating and searching the index pretty trivial once you have that. A quick index you can grep is a oneliner on Linux, something like getfattr -R /music -m genre > index.db

Is that updated atomically with filesystem updates? Can multiple applications access that simultaneously as it changes? Is it a known pattern where you expect the various applications on your system to be using that already?

I'm not really sure what "atomically" means in this context, if you just mean you want the index updated when an attribute changes, then sure why not, just use inotify with IN_ATTRIB.

I don't think anyone is currently using extended attributes like this, so there is no standard pattern. The question was about whether other filesystems can do this, and the answer is yes - basically all modern filesystems.

I guess people have decided they don't think storing this metadata in the filesystem is best place (I don't know why, perhaps because it's complicated to copy the metadata when you email the files to someone else?).

> I'm not really sure what "atomically" means in this context, if you just mean you want the index updated when an attribute changes, then sure why not, just use inotify with IN_ATTRIB.

The answer is it's not atomic, it's another system tacked on the side. The filesystem information and your index can and would get out of sync. You also can't safely access that from several programs simultaneously.

> I don't think anyone is currently using extended attributes like this, so there is no standard pattern.

They were under Be.

> The question was about whether other filesystems can do this, and the answer is yes - basically all modern filesystems.

No, no other filesytems I know will index off of attributes. Your example doesn't even index. It just writes everything to a file, and on updates has to rewrite the whole file, and searches have to iterate through the whole file. It does not do the same things the Be filesystem does, where the attributes get their own b-trees in the filesystem itself. The closest thing would be to load a database as a filesystem.

> The answer is it's not atomic

You'll have to explain it in more detail, if a file changes then the content has to be re-analyzed and the attribute updated to reflect that.

> It does not do the same things the Be filesystem does, where the attributes get their own b-trees in the filesystem itself.

Sure, but you can import them into a sqlite database, it's pretty simple.

Nevermind, I realized what you meant. You mean the attribute might be wrong, but the index always reflects what the attributes are currently set to (wrong or not).

You're right, the index wouldn't be atomic in that sense.

off-topic observation: viewing screenshots on a so-called "retina" class display, wow… screenshots of GUIs before the advent of anti-aliased text sure did age a lot better, in retrospect.

The screenshot in the article has been scaled, it’s not representative of BeOS text rendering.

Reply on news.ycombinator.com