
Practical File System Design with the Be File System (1999) [pdf] - tambourine_man
http://www.nobius.org/~dbg/practical-file-system-design.pdf
======
tqh
If you want to look at a reimplementation of Be File System, here is Haiku's
version: [https://github.com/haiku/haiku/tree/master/src/add-
ons/kerne...](https://github.com/haiku/haiku/tree/master/src/add-
ons/kernel/file_systems/bfs)

~~~
yebyen
+1 for Haiku. I am not a regular user but I listen to the developer list
traffic and admiring hopefully; they are often fighting off the "one troll"
that antagonizes the list, or of course bikeshedding about when and whether to
have the next release, or if they should try and promote the nightlies more
instead, since there hasn't been a release since Alpha4 (2012) and substantial
progress has been made since then.

For anyone who is not in the know about the BeOS revival OS and its current
events, I assure you that Haiku is not dead ;)

The recent addition of package management with recipes and a ports tree
breathes new life to the single-user desktop OS. Two factors that get repeated
by the list-complainers: 1) people that hardcoded some path in their software
product back in BeOS R4/R5 days that needs to change now because package
management (this one either comes from the developers of said product, or the
users, and you can never tell which unless they follow up with a ticket or a
fix)

2) Hardware support is very good, until you get to modern wireless chipsets,
64-bit computers, or USB3. A lot of this comes from drivers ported over from
FreeBSD, which will lag behind by a version or two. So there is a potential
that it will get better, but still unlikely you are going to be able to run
Haiku on bare metal of your brand new brand name laptop from the store with
Blah-Next-EFI-SecureBoot Thing and Windows 10 (or realistically, new computer
you bought in a store even today.) The progress is going to lag behind a bit
because there's obviously non-zero effort required in porting new releases of
any kind of upstream components.

Wooo OT -- but how often does an even tangentially related to Haiku post get
to the front page? I regret nothing.

~~~
teacup50
Haiku lost its project founder and lost its way -- it has been captured by
people whose day jobs are -- literally -- Linux kernel development.

Instead of shipping BeOS R5 and no more, which was the project's goal since
inception, they're bolting on Linuxisms like package management and in the
process getting completely lost in the weeds.

~~~
yebyen
The stated goal of R1 Final has always been complete binary compatibility with
BeOS R5, but seriously that was years ago. Package management is far from "a
linux-ism" \-- you are hard pressed to find a modern operating system that
does not have any infrastructural support for taking candy from upstream.

Proprietary OS is going to push the app store, by converse the free OS is
still going to scale well because the skeleton crew of volunteers can still
keep all the supported binary software up to date with security and
modernization updates (not necessarily related to Haiku) for the masses who
will not compile it for themselves.

You may have some insight that I do not regarding project leadership but I
respectfully disagree that package management is not just "lost in the weeds."
Haiku would not be advancing or at all survivable as a general-purpose OS
without it.

HaikuPorts/HaikuDepot/pkgman is really slick.

~~~
teacup50
Package management is what you need when you have a huge tree of unstable
dependencies that have to be updated in lock-step.

Proprietary OS _don 't have that_, which is why:

1) They can support stable binary-only commercial software, and

2) They do not need or benefit from Linux-style package management.

BeOS R5 had the stable APIs necessary to achieve a stable OS _without_ Linux
style package management. The shift away from that has also involved a shift
away from the idea that the OS should ship ABI-stable libraries.

Linux-style package management isn't an appropriate tier-one feature for a
modern stable desktop OS.

~~~
wcummings
Even if users don't need "Linux-style" package management, developers
definitely do.

~~~
teacup50
Only for "Linux-style" software, and it need not be built into the base
system.

In fact, it should not -- if having a stable system on which binary software
can be shipped is important, a built-in supported Linux-style dependency
management system will undermine that goal entirely.

~~~
yebyen
I don't get "linux-style." It's not linux-style, it's "built-on-free-software"
style. The other style is "I paid someone to do it" style. That's not really a
style, it's just polar opposites.

------
donatj
This is a classic, although over my head in a lot of ways. I've had it on my
bookshelf for years. BeFS with it's awesome metadata capabilities is what
spotlight should have been.

~~~
jason_slack
I think that Dominic works at Apple?

------
rr56
I wanted to take a break (A month or so) from my current project to learn a
bit about file systems. I've played with Xv6s filesystem before and am
interested in reading about bfs, fossil and related arch and modern ideas in
general. Any resources would be really appreciated.

~~~
mtrn
A classic on the UNIX filesystem would be Chapter 4, INTERNAL REPRESENTATION
OF FILES, from: Maurice Bach, Design of the UNIX operating system, 1986. It's
quite short, about 25 pages.

I believe there is an online version available.

~~~
donarb
[http://www.tenox.net/docs/the_design_of_the_unix_operating_s...](http://www.tenox.net/docs/the_design_of_the_unix_operating_system.pdf)

------
indeyets
That's a great book. Far from state of the art these days, but still very
inspiring for beginners.

I took a lot ideas from it, while designing some in-house DB solution 10 years
ago.

~~~
rr56
Do you happen to know of more modern resources?

~~~
indeyets
well… I think it makes sense to look at ZFS and BtrFS.

[http://www.eall.com.br/hp/Solaris/ZFS%20Internals.pdf](http://www.eall.com.br/hp/Solaris/ZFS%20Internals.pdf)
is a nice start. Not as comprehensive as BeFS book, but still

------
brinker
This was the textbook in my file systems class a couple years ago. Great book
that really does a good job of explaining how file systems work.

