Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The BeOS file system, an OS geek retrospective

arstechnica.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: The BeOS file system, an OS geek retrospective

#41

Post by ChristianGeek »

S3raph wrote: post #35

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.

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.

Re: The BeOS file system, an OS geek retrospective

#42

Post by monocasa »

tialaramex wrote: post #11

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 c…

At the time that it was in the market, a "64-bit address space" wasn't the default. There's way more to it than the size of off_t, as it permeates the entire on disk filesystem structure.

For instance, the BSDs didn't have 64-bit block offsets until UFS2 which wasn't a default until FreeBSD 5 in 2003. In other systems, HFS didn't have 64-bit file lengths until HFS+ in 1998. NTFS started as full 64-bit, but you couldn't really get that on a consumer system until WinXP (maybe Win2000 for the prosumer market).

Re: The BeOS file system, an OS geek retrospective

#45

Post by codezero »

fredoralive wrote: post #23
codezero wrote: post #7

Earlier quoted context omitted.

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

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

I assume you are right and I was hasty :)

Re: The BeOS file system, an OS geek retrospective

#46

Post by tialaramex »

monocasa wrote: post #42
tialaramex wrote: post #11

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 c…

At the time that it was in the market, a "64-bit address space" wasn't the default. There's way more to it than the size of off_t, as it permeates the entire on disk filesystem structure. For instance, the BSDs didn't have 64-bit block offsets until UFS2 which wasn't a default until FreeBSD 5 in 2003. In other systems, HFS didn't have 64-bit file lengths until HFS+ in 1998. NTFS started as full 64-bit, but you couldn…

"There's way more to it than the size of off_t"

Nope, the change to off_t is literally all that's behind this claim. It's not Be's claim, explicitly, although they were of course in no hurry to clear it up.

BFS is specifically _not_ itself suitable for huge files. Last time I looked the default Haiku BFS settings won't allow files to grow beyond about 140GB. Which is fine for an ordinary file of course, but you certainly won't be happy if you expected to store a filesystem image _inside_ a file.

This happens because it's a rush job. For example there's lots of special corner case code needed for the extent handling in the multiple indirection case. I can easily imagine a week or two of work just to develop, let alone test, this part of the system. So, instead BFS although it labels these "extents" still just uses a fixed size block so that the code is simpler. It's not a problem at all, for small to medium size files on a defragmented or largely empty disk. But as files get bigger and disks get fragmented... oops.

NTFS dates back to 1993, it takes some real dodging and diving to conclude that NT 3.1 (in 1993) isn't a "consumer system" and yet somehow BeOS, available only to people who swore they were software developers who wanted to write software for Be's new BeBox architecture was.

Re: The BeOS file system, an OS geek retrospective

#47

Post by ModernMech »

cpeterso wrote: post #36

A fun BeOS story from the 1999 Be Newsletter: https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-22.... 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…

> The angled sunlight triggered the write-protection mechanism

How does that even happen?

Re: The BeOS file system, an OS geek retrospective

#48

Post by zmix »

axaxs wrote: post #34
alain94040 wrote: post #9

Earlier quoted context omitted.

What would blow you away today? I’m always curious to know what to build next.

A truly convergent desktop. And I don't even know the details to explain what I would like, I probably wouldn't even know until I used it. I do know Android for Desktop is not it, though. Being able to throw apps from my phone to my pc to my tv would be nice too, and not so clunky as casting.

I would continue, where the ideals of the 60s/70/80s/90s left off. Since IT gets dominated (sponsored) by service companies, book and grocery stores, things are a bit fucked up, to say at least ;-)

Re: The BeOS file system, an OS geek retrospective

#49

Post by tialaramex »

tialaramex wrote: post #11

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 c…

It's apparently too late to edit this comment, so I must annotate: O_LARGEFILE isn't part of POSIX, it's an extension, my error there entirely.

Re: The BeOS file system, an OS geek retrospective

#50

Post by m_eiman »

memsom wrote: post #28
m_eiman wrote: post #22

Earlier quoted context omitted.

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).

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.)

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…
Post reply on HN