Sure, in computing terms 1998 is an eon ago. But that's not a good reason to stop using a file system. Lots of older file systems are still in use: FAT32 (1996; still the default for SD cards <32GB and anytime you need a cross-platform filesystem), XFS (1994; the new default filesystem for RHEL7), NTFS (July 1993; WinFS still hasn't materialized), and ext2 (January 1993; still commonly used, particularly in situations where a Journal is not required).
Of course, I'm perfectly happy to believe that HFS+ is more badly-designed than any of the other filesystems from that time. But a filesystem doesn't need to be replaced just because it's no longer trendy.
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'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)
And there is http://code.google.com/p/maczfs/ and http://downloads.maczfs.org/
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.
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.
And yet, he goes to mention tons of changes to the FS over the years, including journaling...
* 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.
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.
Checksums wouldn't have fixed this, they'd only alert the user to the fact the damage had already been done, which is exactly what the decompressor did in its own special way.
As another comment points out, error correcting codes are the way to handle this, and its already done in hardware, and probably too expensive to do in software in the general case
Imagine you have weekly backups , but only for the past 26 weeks because of disk space. A file gets corrupted, but you only view it a year afterwards. You effectively have no way of recovering it.
Knowing something is wrong can be useful (though being able to fix it is even more useful).
Needless to say I no longer keep anything of consequence on non-checksummed filesystems now.
I've never had a single byte of corruption. Not one, not ever. The data is checksummed about once a month.
26 is a very high number for a deterministic system compared to zero.
My recentish MBP purchase (2011) resulted in a single corrupt file copying 1/3 of that volume onto the machine over the LAN. this was 10.7 at the time. That scared me a little.
The Linux kit I operate has had no discernable data corruption either in the last 12 years.
I know this is an anecdote but over time that's a huge cumulative error.
I've been using Macs for 5 years now. I've stored time machine backups spanning two drives and OS releases from snow leopard to mavericks. (Each drive was used for about 2.5 years, and the OSes were installed soon after they became available.)
Every 9-15 months, I ask Disk Utility to repair the Time Machine volume. The first time, I lost the entire TM directory and had to format the drive and start over. The second time, it crashed Disk Utility because there were so many errors. The third time, I lost the older ~70% of my backups. The most recent time, the operating system refused to even recognize the disk as an HFS+ volume!
Each time, I had the opportunity to format the disk in question and check it for hardware issues. They all passed badblocks and SMART with flying colors. In addition, the volumes were unmounted properly the vast majority of the time (a few instances of human error and power outage)
tldr: HFS+ loses your data catastrophically even if you use it properly.
By the same token, I've experienced much more corruption on my ZFS (~200TB) and btrfs (58TB) arrays over the last few years than I have on HFS for a decade.
A modern computer does more operations in a single second, than a small country can buy lottery tickets in a lifetime.
Many wildly unlikely things become quite likely with computers.
Checksums at the FS level are very rare; the majority of the ones in use don't have them (http://en.wikipedia.org/wiki/Comparison_of_file_systems ) and yet they function perfectly fine. HFS+ is not the problem here.
http://queue.acm.org/detail.cfm?id=1317403 is a good article by someone at NetApp describing everything which can go wrong with hard drives, including this class of error.
There are two good papers on measured real-world error rates:
http://indico.cern.ch/event/13797/session/0/material/paper/1... http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
The good news is that many of these errors were caught but there are examples which were not and the real message is that the entire stack has enough complexity lurking in it that you wouldn't want to simply assume it handles something as critical as data integrity. Something like the ZFS / brtfs approach is nice because it doesn't depend on all of those layers working as expected, is guaranteed to be monitorable and is much less likely to silently change without notice.
http://research.cs.wisc.edu/adsl/Publications/parity-fast08....
I don't think the implication is that the fs is at fault for the corruption - it's just at fault for failing to detect it. Hardware problems tend toward certainty over long enough time scales - doesn't it make sense to defend against it given the relatively minimal cost of doing so?
> Checksums at the FS level are very rare; the majority of the ones in use don't have them .. and yet they function perfectly fine.
No, they too allow data to silently become corrupt in face of imperfectly functioning hardware. Sure, it normally doesn't happen, but it's certainly not rare enough to warrant ignoring if your data is in any way valuable to you.
Anyway, are you arguing that filesystems shouldn't bother with checksumming at all?
This isn't a replacement for something better, it just allows simple bit errors to be corrected automatically by the drive. The problem is that it's not really obvious when it's happening, and you only notice when it can't fix something. Drives eventually throw a SMART error when it's had to do too many corrections though.
It may have been great if Time Capsule, or an Apple NAS uses ZFS. But it seems Apple will likely wants you to move everything to iCloud Drive( Finally! ).
I think Apple's new FileSystem will be based entirely for Flash. Something similar to Samsung's F2FS. Since F2FS is GPLv2 license it is not possible for Apple to use it within their own Kernel.
I am not sure that is the reason. Apple did already announce it at WWDC after all. ZFS on OS X was announced in June 2007. In September 2007, NetApp sued Sun over patents violations in ZFS.
It's likely that Apple didn't want a patent suit after adopting ZFS as their main file system. 2007 Apple was of a completely different size as 2014 Apple.
ZFS support made sense for Mac OS X Server back in 2007. It's a beefy server filesystem that rewards beefy servers with gobs of ECC RAM, RAID, and no battery to worry about.
ZFS as default replacement for all of Apple's HFS+ usecases (laptops, iPods, phones and tablets in the works) made no sense in 2007 and makes no sense in 2014. ZFS is simply too resource intensive and too dependent on ECC RAM even now for consumer use cases.
All other filesystems are equally susceptible - if your memory is getting errors, they'll happily write those to disk too.
http://www.ixsystems.com/storage/freenas/
ZFS to stop the bit rot!
I found the same issues on my music, video and photos collections.
However, as a casual observer and long time ZFS wanna-be, I've noticed that the following two issues haven't really gone away:
1) Which version of ZFS? After Sun was assimilated by the Borg and after the great ZFS developer diaspora, everyone seems to have their fingers in the ZFS development pie. There are a plethora of derivative versions. Nothing wrong with that, but when there was a single canonical version there were "many eyes" on it. Bugs were hunted down and squashed. But now? Every "port" to a different OS variant introduces new opportunities for bugs, doesn't it? Is ZFS on FreeBSD as stable as on Solaris? And FreeNAS isn't pure FreeBSD, have they tweaked ZFS?
2) When ZFS is working, it's great. But it doesn't seem to simply fray around the edges. When it fails, it fails catastrophically. I've seen much advice on mailing lists to "restore from backup" after something goes wrong.
I recently bought and returned three(!) 3TB drives because I found they were silently corrupting data every 500GB of writes, or so (verified by testing on multiple systems) - I switched to 2TB from another brand, and had zero issues. I only knew there was a problem because I wrote a burn-in script to copy & verify over and over. File system, OS does not care. It's the drive's job.
Almost every USB stick I've ever used eventually had some small corruption issue - again, no way to catch this unless you are looking for this kind of thing.
Average consumer does not think this is even possible - the idea of your data silently getting scrambled seems impossible, like a car randomly being unable to break - it is just assumed this sort of thing does not happen. But as hard drives get bigger and people put more RAM in their systems I think this will become a huge issue. Of course, consumers will blame "a virus" or something along those lines.
"Who the f*ck are they to send me reliability patches, when they can't even get the basics right?"
I remember reading Microsoft made a push to get hardware vendors to use ECC Ram with Vista - they recognized a lot of crashes were due to this (but XP would get the blame). No go.
Or just back it up daily over the network to a Linux server in my closet?
That's a good number for average users. No one is using HFS+ as a file server. Users who have lots of data use external backup devices (which are prone to HW failure, especially the WD external HDs) or oversight backup services.
ps. Anyone used this[1] on macosx? Can it replace HFS+ in the root partition?
UPDATE: The faq clearly states that it can't be used as a root partition:
Q) Can I boot my computer off of O3X?[edit] A) No. O3X cannot be used as your main system partition.
what a pitty :-(
I used to work with ZFS for a living, so I want it to work - maybe that makes me biased.
I wrote an article on the wiki[0] on CoreStorage and Encryption together with ZFS and it's been working as expected for a couple of months now.
I currently use it to test family/friends backup with SyncThing[1] to see if it can make a (although bit hacky) viable backup solution for the common man, with file history based on routinely snapshots (which will make problems, e.g. how Dropbox explicitly doesn't sync open word documents, how a VMs disk image might not be super great to backup "as is" while in use).
As a final note: it can not replace HFS+ for TimeMachine backup either.
In the same situation, HFS+ would let you make a backup of corrupted data. If you don't keep all your historical backups, you may end up unwittingly tossing out the last backups with good versions of those files.
I'm sorry, I don't understand your last sentence.
This is exactly backwards - metadata checksums don't protect file contents. They just cover the integrity of the FS so when the FS internals are corrupted, it knows not to write to random places on the disk and can with redudancy can try to recover the metadata.
