Here's the thing. I used FAT16 for years and years and years and never had a problem. I used FAT32 for the majority of a decade and never had a problem. I used NTFS for a number of years and never had a problem.

While NFS+ isn't quite as bad right now, I can tell you that the 10.4-10.5 days it seem to enjoy corrupting files. You rebooted your computer? Here's a couple of missing files in your trash. Hope you can find what binary thing on your multi hundred gigabyte disk they fit in.

NFS+ is the ONLY filesystem I have ever used that I have lost bits of data on from silent corruption. I don't trust it. I would kill for Apple to adopt ZFS or NTFS. At this point I want it check summing all of my files and my filesystem so I know that it's not being corrupted silently by the OS making weird mistakes on a filesystem that should've been replaced 10 years ago and is just hack after hack on a system designed for a computer that only had 128 K of memory.

I love everything about OS X. Except HFS plus, which needs to die in a fire.

Nothing is quite as much fun as looking at an old picture or listening to a song I haven't listened to in quite a while just to find that it's actually silently corrupted and has been for multiple years and I probably don't have the correct version on a backup.

I'd trust ext2 over HFS+.

Yes, I'm bitter.

>I used FAT16 for years and years and years and never had a problem. I used FAT32 for the majority of a decade and never had a problem

>I'd trust ext2 over HFS+.

>Yes, I'm bitter.

Unfortunately not only bitter but bitter to the point of senseless argument just of the sake of argument. Trusting a non-journaled FS over a journaled without error correction/detection is a bad choice, like career-limiting bad. And if you never had problems with FATXX then you most likely never used DOS or old Windows seriously. Corrupted data and specifically corrupted MBR was really frequent back then (like corrupted b-trees on the Mac side)

Most journals are metadata-only, so they save you from corrupt directories but don't protect contents at all. NTFS loves to wipe out just-written files when I lose power, for example. Files that previously existed, mind you, now suddenly garbage.

> And if you never had problems with FATXX then you most likely never used DOS or old Windows seriously

Ah, the joy of "ghost" folders that ended up containing themselves...

It's journaled now. I used DOS and Windows for years and never had any real problems (well, on hard drives, floppies were more vulnerable).

Afaik, around Mac OS X 10.5 had native ZFS support (but not as boot partition).

And there is http://code.google.com/p/maczfs/ and http://downloads.maczfs.org/

They promised it at WWDC when they announced 10.5, but silently scraped the feature before release.

ZFS was never promised as the way forward for the default filesystem on consumer machines.

The truth is despite all the Siracusa "We Want ZFS" nonsense, it's an absolutely terrible choice for a consumer filesystem. All of the nice features come at the cost of it eating an enormous amount of RAM and CPU resources, and it's integrity guarantees are meaningless if the machine isn't running ECC RAM anyways.

Apple was never going to ship laptops running 10.5 where 4 Gigs of RAM were immediately eaten by the filesystem and battery life was halved from 10.4 due to the extra CPU load. ZFS as the default for OS X was always pipe-dream nonsense promoted by people with no understanding of or experience with ZFS.

And equally you're over exaggerating the demands ZFS has; it runs quite happily on lower end hardware. Granted you need a 64bit CPU, but all Macs are shipped with one anyway. And unless you have deduping et al turned on (which you don't really want on a desktop anyway), the CPU load would be minimal. You could probably even get away without compression as well (though the modern algorithms ZFS supports are pretty light on the CPU).

As for memory, the minimum you need for pre-fetching is 2GB of free RAM. ZFS will, however, run on less with pre-fetching turned off.

The thing with ZFS is that it will consume your RAM and CPU if you have all the uber features enabled and a boat load of pools created, but since you don't need nor want that on a desktop, ZFS shouldn't need to be that resource hungry.

What's more, part of the misconception of ZFS's bloat comes from the age of the file system. My original ZFS server was less powerful than most budget laptops these days (and I was running a small number of VMs off that thing as well)! So modern systems definitely do have the resources to run ZFS as their desktop fs.

I still trust non-ECC RAM a lot more than my disk.

Behold what I believe is the spiritual successor and which I'm going to play around with pretty soon: https://openzfsonosx.org/

HFS+ hasn't exactly failed me spectacularly, but I'll be more at ease with my sensitive and valuable data on ZFS.

NTFS isn't a single bit better than HFS+ in terms of checksums.

Also, HFS wasn't used on the original Macintosh 128K -- that used a simpler filesystem called MFS. HFS was introduced with the Mac Plus a couple of years later.

NTFS may not checksum everything, but I also never had it silently corrupt my files and helpfully provide me the 'missing parts' when I rebooted.

The most terrible thing with silent corruption is that, unless you verify your data, you'll never know it happened because it's, well, silent.

Have you checksummed your files lately?

I've experienced silent corruption on NTFS. And it still modifies data in-place, so an unlucky power failure or reboot could still cause data loss. Thankfully Microsoft already have an answer, ReFS: http://msdn.microsoft.com/en-us/library/windows/desktop/hh84...

Silent corruption can hit NTFS just as well. The only protection is to have a good hardware with ECC RAM, raid with redundancy and a FS that checks data on every read like zfs,btrfs,ReFS,... and backups.

> But a filesystem doesn't need to be replaced just because it's no longer trendy.

The author wasn't just saying that its age was damning, it was the fact that the FS hasn't changed much since 1998.

Since XFS was mentioned, I wanted to mention that it's hard to compare to HFS. The author mentions HFS' stagnation, but XFS has seen tons of improvement since 1994. It seems like I'm reading about some cool new XFS development every year. NTFS has made progress since its early years, too.

>The author wasn't just saying that its age was damning, it was the fact that the FS hasn't changed much since 1998.

And yet, he goes to mention tons of changes to the FS over the years, including journaling...

Yeah, I'm not sure what the difference is between what the author calls "hacks" and others call "updates."

Some of these updates are clearly hacks, in the sense that if you did not have to worry about backward compatibility, they would certainly not be implemented in that way.

They're not like upgrades from ext2 to ext3, it's like ext2 was modified in a weird way to support new features that older ext2 implementations do not know about.

Hard Links for example are implemented by adding files which look a lot like symblinks. As soon as you create hard links to a file, the file is moved into a invisible folder named "Private Data" and becomes a "node file". The original file is replaced by a stub containing the CNID (special type, special content). That's not as efficient as having iNodes and hard links from day 1. If you mount such a volume on Mac OS Classic, the "Private Data" folder is totally accessible and modifiable by the user, and of course hard links do not work.

Hot file clustering and journaling are implemented in similar ways to hard links (invisible folders).

The opposite example are extended attributes (xattr) which were added in 10.4. A special filesystem structure named the "Attributes File" was reserved in HFS+ from day 1 but never used. De-defragmentation does not rely on any changes to the volume, it's purely done in the Filesystem driver stack.

Things like Copy-on-Write or Snapshotting, are probably impossible to implement in a backward compatible manner though...

> They're not like upgrades from ext2 to ext3, it's like ext2 was modified in a weird way to support new features that older ext2 implementations do not know about.

It's my understand that this is exactly what ext3 is, though! It's designed to look like ext2, but with some extra hidden stuff for journaling...

Yes, in fact, we used to convert ext2 to ext3 with one single command:

  tune2fs -j /dev/<device>

This adds a journal to the filesystem, making it ext3. In fact, you could mount ext3 as ext2 (you probably still can). It would just not replay the journal.

The same is pretty much true for ext4, it primarily consists of extension for ext3, but forked as a separate filesystem in order not to destabilise ext3. You can mount an ext2 or ext3 filesystem as ext4. You can mount an ext4 filesystem without extents as ext3.

It should also be noted that ext2 is strongly influenced by UFS1 (FFS), which has been around forever.

ext[234] is not a modern filesystem. However, it is very well understood and stable.

Indeed, ext3 nor ext4 would have been implemented the way it is if it didn't have to worry about backwards compatibility.

How often can you actually implement new features in an entrenched filesystem and not have to worry about backwards compatibility. This is the case for ext2/3/4, NTFS, and I'm sure many others.

Nobody is suggesting that things are bad because they're old. They're saying that HFS+ model older design practices that aren't relevant for modern file system designs and expectations. And what's more, you're kind of disproving your point with those examples:

* FAT32 is frequently criticised for being crap and the FAT32 variants that fix many of it's short comings are often stuck behind Ms patents. In short, FAT32 is a terrible file system that needs to die more urgently than HFS+.

* ext2 isn't really used for anything other than a direct replacement for FAT32. It's not really a practical fs for modern systems and shouldn't really be used on one.

* NTFS isn't a static file system. It's like saying ext is decades old when ext4 is practically a whole other file system to ext2 (while still offering some degree of backwards compatibility). NTFS is similar in the way how it has incremental versions. However even then, NTFS does still have it's critics and, as you mentioned yourself, MS have tried to replace it on a few occasions.

XFS is really the only example you've come up with that works in your context. It's also one of the few file systems I don't have any personal experience with so I couldn't answer how it's managed to keep up with the pace of technology.

Age isn't the argument that I see. The writer is complaining that HFS+ has failed to keep up with modern needs.

HFS+, very much unlike nearly every other filesystem in existence, was designed with only one real feature in mind: associating "resources" with "files." As I understand, HFS+ has two master files; one contains icons, filenames, metadata, etc., and the other contains the file data streams. This design is extremely prone to fragmentation, and it was created with static oversimplified data structures that are not forward-compatible with advances in storage features and capacity.

As a result, HFS+ simply can't meet the needs of a modern computer user the way virtually any other *nix-ish inode filesystem can. It doesn't have room in its data structures for proper error correction or failure recovery, and it's impossible to achieve atomicity or any reasonable level of reliability and performance.

Virtually every other modern filesystem has those attributes, and for good reason: They're supposed to be reliable.

Are filesystem-related issues common among the half billion devices running OSX/iOS? I believe hardware completely overshadows software re. storage reliability and performance.

Instead of using ext2, just use ext4 (2008) without a journal to get 16 Years of Progress :)

The two biggest problems I have with HFS+ are no sparse file support and the catalog file (limits concurrency). It would be nice to have timestamps better than 1s too.