
The BeOS file system, an OS geek retrospective - Tomte
https://arstechnica.com/information-technology/2018/07/the-beos-filesystem/
======
cpeterso
A fun BeOS story from the 1999 Be Newsletter:

[https://www.haiku-os.org/legacy-
docs/benewsletter/Issue4-22....](https://www.haiku-os.org/legacy-
docs/benewsletter/Issue4-22.html)

A Testing Fairy Tale

Two test engineers were in a crunch. The floppy drive they were currently
testing would work all day while they ran a variety of stress tests, but the
exact same tests would run for only eight hours at night. After a few days of
double-checking the hardware, the testing procedure, and the recording
devices, they decided to stay the night and watch what happened. For eight
hours they stared at the floppy drive and drank espresso. The long dark night
slowly turned into day and the sun shone in the window. The angled sunlight
triggered the write-protection mechanism, which caused a write failure. A new
casing was designed and the problem was solved. Who knew?

~~~
ModernMech
> The angled sunlight triggered the write-protection mechanism

How does that even happen?

~~~
derefr
Probably similar to how optical key-switches work: the floppy drive would
shine a laser or LED through the write-protect notch and watch for it on the
other side with an optical sensor to know whether the disk was write-
protected.

So, in a not-write-protected disk (no through-hole), the laser light couldn’t
make it through to the sensor... but sunlight sneaking in through the drive
casing and under the disk still could.

------
Tomte
Also interesting: Practical File System Design with the Be File System

[http://www.nobius.org/~dbg/practical-file-system-
design.pdf](http://www.nobius.org/~dbg/practical-file-system-design.pdf)

~~~
brazzy
Seconded, I owned that in printed form, and it is very well-written

------
udkyo
BeOS was delicious all around and it's a crying shame it didn't take off. It
really felt like the Amiga's spiritual successor to me.

~~~
discreteevent
Apparently a few of the developers are working on Fuchsia so maybe some of the
ideas will make it there.

~~~
jacobush
Possibly. The problem is, for some designs to really work, you need someone at
the helm not only incorporating the good ideas, but also saying _NO_ to
anything that does not fit the vision. (iPhone etc comes to mind.)

Many open source projects and commercial projects too tend to be much more
inclusive in what they pick. The end result often becomes something like when
Homer Simpson designed a car. Oh that's neat! [1]

1: [https://laughingsquid.com/wp-
content/uploads/2013/07/homer2....](https://laughingsquid.com/wp-
content/uploads/2013/07/homer2.jpg)

------
sohkamyung
It's a reprint of an article from 2010, so perhaps (2010) should be added to
the HN title, in case people are expecting to read something new about BeOS in
2018.

~~~
Theodores
Which is typical of the product and the era.

BeOS was like those Transmeta Crusoe CPUs, Segways and other products that
gave journalists something to write about even if adoption was not going to
happen.

The circus aspect of the media wanting to write something (as they have pages
to fill and eyeballs to feed) must be quite costly to small companies wanting
to get a legit product out there. I can still remember the name of Jean-Louis
Gassée from his frequent soundbites in the tech press about the wonders of
what BeOS was going to be. Did he actually do anything in between conferences,
interviews and scheduling media appointments? If so, how did he get the time?

The 'look what we could have won' tech retrospectives are also part of this
media cycle, a version of garbage-in-garbage-out applies where those companies
that got hyped get recycled as article-worthy a decade on...

~~~
exikyut
I find it sad this is being downvoted. I think this rings true.

Perhaps too true?

HN has its bents and focuses, but it's at least more conversationally balanced
than reddit (perhaps
[https://news.ycombinator.com/item?id=15965536](https://news.ycombinator.com/item?id=15965536)
partially explains some of the reasons why). The news media is of course pure
bias and content/distribution/agenda masquerading as fact-based objectivity
(eg, [https://youtu.be/hWLjYJ4BzvI](https://youtu.be/hWLjYJ4BzvI)).

Where else can I look for... the kind of apolitical, discussion-focused
information sharing that eg used to happen on blogs circa 2007, but in
discussion community form, and within a community framework that is bias-
resistant?

------
tialaramex
Most important thing wrong with this article is that it keeps talking about
BeFS having a "64-bit address space". That's not so at all.

BeOS has the equivalent of the POSIX O_LARGEFILE permanently enabled.
Historically 32-bit Unix systems assumed files were no larger than 2^31 bytes
for the purposes of random access, and a feature labelled O_LARGEFILE says
that your program wants 64-bit offset values instead so you can seek inside a
larger file. In a 64-bit OS this doesn't make any difference to anything, and
in modern programs O_LARGEFILE will always be set for 32-bit programs too.
This isn't about the filesystem at all, on BeOS, or any other Unix-like
system.

BeFS does, like a lot of modern filesystems, theoretically support larger
storage than is ever likely to be in the hands of ordinary end users. Many
petabytes of storage in a single filesystem are in principle possible with
BeFS. But that's not strongly related, in either direction, with the use of a
64-bit integer for file seeking.

Beyond that BFS has lots of annoying problems, which are very understandable
in the context of it being rushed into use over such a short period of time
and with really only one key person doing much of the work, but they don't
vanish just because they have an excuse:

The metadata indices are clearly aimed at end user operations like "Where's
that file with the client's name in it?" or "What songs do I have by Michael
Jackson?" but they're designed in a way that wastes a lot of space and yet
also has poor performance for such queries - because they're case sensitive
for no good reason. They also incur a LOT of extra I/O so if you don't need
that feature you'd really want to switch it off, but you can only really do
that at filesystem creation time.

Fragmentation is a really nasty problem. This is an extent-based filesystem,
so that's somewhat inevitable, but BeFS almost seems to go out of its way to
make it worse, and provides no tools whatsoever to help you fix it. It's
actually possible to get a "disk full" type error when trying to append to a
file which is badly fragmented, even though there is plenty of disk space.

Unix files often have an existence that transcends the mere name on the disk,
but BeFS takes that a step further, allowing application software to identify
a file without knowing its name at all. There are a few scenarios where this
is quite clever, but if you ever want to retro-fit actual privilege separation
to the OS (which has been a long term ambition for Haiku for more than a
decade) this produces a Gordian knot - permissions are associated with names,
but software can simply obtain (or guess!) the anonymous number for the file
and sidestep such permissions altogether.

The journalling has a nasty hole in it. There's no way to safely delete files
using the provided metadata journalling and recover the freed space, so, in
practice if you crash while deleting files some of the space is just
mysteriously gone until you run a "check" tool (remember the scorn for such
tools in the article...) to find and recover it.

~~~
fanf2
4.4BSD systems on all architectures had 64 bit off_t since the early 1990s.
It’s a crying shame that Linux didn’t copy more good ideas from the BSDs :-/

~~~
sureaboutthis
It's a crying shame we aren't using BSD more, period.

~~~
dman
Some of us are.

~~~
apple4ever
A lot of us are (MacOS)

------
jjgod
Tidbit: Dominic Giampaolo, the creator of BeOS file system, is also behind
APFS (he gave a WWDC talk back in 2016:
[https://developer.apple.com/videos/play/wwdc2016/701/](https://developer.apple.com/videos/play/wwdc2016/701/)).

------
gigatexal
Having never played with BeOS but dabbled with Haiku — the richness of the
BeOS filesystem would have won me over in a heart beat. Imagine if Microsoft
bought them and then actually shipped a proper reFS that had the same
richness? Or if Apple had — meh, Apple should have just paid Oracle the
license fees and licensed ZFS. Or co-opted openZFS (not sure if that’s
possible either, legally).

~~~
jacobolus
Apple hired the author of BeFS to work for them. He has worked on Spotlight,
Time Machine, Apple's file systems, etc.
[http://www.nobius.org/dbg/](http://www.nobius.org/dbg/)

~~~
jacobush
Maybe that is why macOS has a similar way to access files by ID instead of by
path?

The .vol directory:
[http://www.westwind.com/reference/os-x/invisibles.html](http://www.westwind.com/reference/os-x/invisibles.html)

~~~
m_eiman
I think that's a legacy from MacOS Classic, where there was a way of keeping a
handle to a file that was independent of the file's name (so you'd still point
at the same file even if it was renamed).

~~~
memsom
You might find the file handle stuff comes from the fact that a lot of the Be
employees were originally Mac developers at the start, and quite possibly
because they wanted to support some of the features that were in the OFS
(original File System, the Database like file system BeOS originally shipped
with right up to the AA/PR1 releases. DR8.x definitely had the old file
system.)

~~~
m_eiman
I remember reading some BeOS API documentation where it said something like
"paths are UNIX-like, entry_refs are MacOS-like and they each have some pros
and cons". Can't find it now, though…

------
S3raph
I still remember running the r5 release on my Pentium III 450Mhz..never had
such a lagfree and fast multimedia experience on any OS.. ZERO lag.. it's
performance was amazing.. unfortunately it's lack of hardware support and
multiuser made it problematic to use it as a daily driver. Even Beos Zeta
(commercial version based on r5) did not really improve the situation.

~~~
ChristianGeek
I did the same thing on whatever Mac I had at the time. (It was the pre-Jobs-
comeback era when Apple was slowly running the Mac into the ground...kind of
like now.) It really opened my eyes as to how fast the Mac hardware could be
and how slow the Mac OS was.

------
bokchoi
> It's pretty clear that some of the functionality that existed in BFS does
> _not_ belong in the FS.

Does anyone know what functionality the anonymous developer is referring to
here?

------
pbreit
Why would BeOS not be open source at this point?

~~~
codezero
Bought by Palm, then HP, then ??? I guess, try to navigate that corporate IP
nightmare.

~~~
fredoralive
I think BeOS went Palm -> PalmSource -> Access (the embedded web browser
people).

~~~
codezero
I assume you are right and I was hasty :)

