> OS X has a fundamentally unreliable filesystem
Unfortunately so is every other filesystem. Which is also why Apple heavily emphasizes making backups.
Unfortunately so is every other filesystem. Which is also why Apple heavily emphasizes making backups.
Do people just read the "pros" and not the "cons"?
You've also failed to quantify why ZFS is "totally broken for regular desktop use" (likely because you've never actually used ZFS so can only blow smoke about it's issues).
People love to over exaggerate the RAM requirements for ZFS because they see build logs of enterprise-grade storage servers. But you wouldn't expect that kind of throughput on your desktop systems even with lighter file systems. And most desktops have their 64bit CPU sat idle for most of the time, so there's not even an argument for the additional instruction overhead.
Obviously the real crux of argument is "what do you primarily use your desktop for"? If it's gaming, then there's little point running ZFS since you're going to be disinterested in the benefits of ZFS (plus likely running Windows anyway). However if your desktop is a development machine, used for multimedia authoring or even just an internet terminal (like most PCs are these days), then ZFS is a viable option.
HFS+ is creaky, ancient, but battle-hardened.
ZFS is solid and battle-hardened, but not that suitable for many of Apple's customers, who want the ability to unmount disks they added, and who will not understand that they need huge amounts of RAM (they their Macoboks don't have) to keep their disks speedy,
btrfs is promising but not battle-hardened yet, and it is very unlikely Apple will use it as long as it has a GPL license (I think it is more likely that Apple will add checksums to HFS+ in some somewhat clumsy, but working, way than that it starts supporting btrfs)
If you think HFS and HFS+ are battle-hardened I don't know what to say to you. "Shell-shocked" would be a better description.
I would generally agree that it's rare for e.g. HFS to corrupt its own metadata due to bugs but bit-rot happens. If you think you haven't encountered it, you probably haven't actually checked your files closely enough – this is particularly easy to miss with things like video or image formats which were designed to tolerate a few bit-flips.
The reason why so many Mac users were interested in ZFS was that a modern filesystem incorporates strong integrity checks so you are guaranteed to either read back the bytes you originally wrote or get an error. That's a much better way to work than requiring you to use a tool which does strong hashes periodically to see if anything has broken.
A lot of consumers are quite obvlious to bit rot. As you point out - most of this occurs in large media files which they are unlikely to notice. Even with things like corrupted documents they will likely blame it on an application glitch.
With ZFS they will see scary diagnostic messages. Consumers will want their SSD or RAM replaced. (ZFS does a great job of catching RAM errors on systems without ECC)
This would no doubt drive higher warranty costs for Apple and cause consumer dissatisfaction.
Ignore is bliss...
I'm skeptical that a proactive warning would be more dissatisfying than just finding it out years later, when other copies are harder to locate. In particular, I'd be surprised if a hypothetical feature like this wouldn't be integrated with their other services: “A local failure was detected and replaced with a pristine copy from iCloud”
The other really interesting question would be whether they'd ever consider something like the ZFS copies feature to directly trade maximum disk capacity for redundancy. That'd be much easier to implement for Apple since they control so much of the platform and the largest files which most people have tend to be things which are provably known to be local copies of something which can be re-downloaded, so the total cost of doubling storage for unique local files might be worth the peace of mind for many users.
I suspect the decision not to use ZFS was (assuming it wasn't simply spite at Sun pre-empting Jobs' announcement) that it would cause dissatisfaction, but from a different direction: ZFS was designed for Sun's customers: companies employing dedicated sysadmins. ZFS was incredibly unfriendly back when Apple would have been evaluating it. User experiences like "you filled up your filesystem? Oh well, you'll have to reformat and restore from backup." may be acceptable in an enterprisey setting, but aren't going to cut it with the iMac crowd.
In the same logic people had issues with ZFS too.
"With issues" means nothing. The number and severity of them only has meaning, and even that only comparatevely.
You're a very lucky man, then. A large part of my time, at one point in my life, was spent fixing up corrupted HFS filesystems.
Also, why wouldn't you be able to unmount a ZFS disk?
zfs unmount ...
Generally though, you wouldn't want to manually unmount file systems unless you're planning to migrate them to a new host. In which case you would export them instead:
zpool export ...There are multiple businesses which sell software which exhaustively attempts to recover data from corrupt drives & cards.
It's a standard service listed on the local phone / computer shops.
I see messages on my neighborhood's mailing list every so often from someone looking for help recovering as much as possible from a flash card.
It's simply absurd to claim that the status quo works for the general public. It's not terrible, probably not that different from various mishaps which befell printed photo albums, etc. but there's still plenty of room for the industry to give people safer tools.
Use ZFS if you like, or XFS, or even ext4 instead.
Second frequent problem: Hitting 90% capacity in a filesystem has a non-trivial chance to ruin it forever. Hit the wrong code path, and, even if you immediately delete a bunch of things, I/O to that filesystem would be forever 3000% slower.
You only have to glance through this thread to see that there are people (myself included) who run ZFS on their desktop machine (laptop in my case).
People love to over exaggerate the RAM requirements for ZFS because they see build logs of enterprise-grade storage servers. But you wouldn't expect that kind of throughput on your desktop systems even with lighter file systems. And most desktops have their 64bit CPU sat idle for most of the time, so there's not even an argument for the additional instruction overhead.
Obviously the real crux of argument is "what do you primarily use your desktop for"? If it's gaming, then there's little point running ZFS since you're going to be disinterested in the benefits of ZFS anyway, so it's not worth the marginal overhead. However if your desktop is a development machine, used for multimedia authoring or even just an internet terminal (like most PCs are these days), then ZFS is a viable option.
Most "desktops" today are in fact laptops, and the reason you want to have the CPU sit idle is battery time.
>However if your desktop is a development machine, used for multimedia authoring or even just an internet terminal (like most PCs are these days), then ZFS is a viable option.
If you're not pooling disks together but just have the built in disk, and usb hard disks that you conenct occasionally you don't get much if anything from ZFS, but you get the penalties it incurs...
And it's not a substitute for backing up your disks either...
That's a fair point. I'd argue that ZFS doesn't chuck that much extra CPU time that most people would notice. However if you're one of those guys that likes to tweak your power settings to the nth degree, then ZFS probably isn't best. But those kinds of people are more likely to run a tiling WM instead of a full fat compositing desktop environment; and such like. So they're definitely not your regular desktop users
> If you're not pooling disks together but just have the built in disk, and usb hard disks that you conenct occasionally you don't get much if anything from ZFS, but you get the penalties it incurs...
You seem to have missed quite a number of useful ZFS features off your list. Ignoring deduplication (as that is extremely memory and CPU hungry), ZFS has snapshotting, checksumming, superblock recovery (even if your journal gets trashed, you can recover it), online data integrity checks (no annoying wait screens for fsck to run through), better compression algorithms than is supported in most other file systems...
I could go on, but suffice to say that ZFS is an improvement over many other file systems in other areas than just software RAIDing.
That all said, in an ideal world desktops would be running HAMMER (DragonflyBSD's file system) over ZFS. I do love ZFS, but HAMMER seems a slightly better fit for desktops / laptops as it has the aforementioned features but without many of the data centre stuff that home users wouldn't need. A better compromise. However I don't see much interest for HAMMER outside of Dragonfly.
> And it's not a substitute for backing up your disks either...
Nobody suggested it was. However ZFS does also have backup features built into it too.