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.
A great deal of mindshare has been eaten up by Linux. And Linux has largely "grown up" and has incorporated many ideas (and in some cases code) from the commercial Unixes. But I do wonder how many people are out there who have broad perspective and ability to push things forward at the OS level.
Also, back in the 90s I feel like systems programming was cooler and had more cachet. Even if people weren't actively writing code for their OS of choice, the icons of programming were the folks working on the guts. Nowadays, I think the cool stuff is all happening pretty far up the stack, and that there are relatively few people working on the substrate.
That's just my impression though. I'd be delighted for someone to look at kernel and system contributions to Linux, IllumOS, and the BSDs and convince me that there is sustainable mindshare to go around, and that all these OSes have a bright future.
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).
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.