HFS+ Bit Rot - Hackdot

Re:HFS+ Bit Rot by ksec on Wednesday June 11, 2014 @01:06AM (#7876580)

The reason why ZFS didn't plan out were simply because it was using too much CPU and Memory. Not something worth considering when the majority of Apple's devices now are Mobile ( Phone / Tablet / Laptop )

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.

[ Parent | on HN ]

Re:HFS+ Bit Rot by danieldk on Wednesday June 11, 2014 @05:14AM (#7877070)

The reason why ZFS didn't plan out were simply because it was using too much CPU and Memory.

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.

[ Parent | on HN ]

Re:HFS+ Bit Rot by msbarnett on Wednesday June 11, 2014 @02:12PM (#7879485)

They announced support for it, not that it was the new default. Big difference.

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.

[ Parent | on HN ]

Re:HFS+ Bit Rot by rodgerd on Wednesday June 11, 2014 @03:11AM (#7876787)

ZFS isn't particularly consumer-friendly, either. Explaining why you can't delete files from a 100% full filesystem, or the pain and complexity of trying to move from 512 byte to 4096 byte sectors and so on would be a nightmare. And of course the design assumes high-quality hardware (ECC RAM for example).

[ Parent | on HN ]

Re:HFS+ Bit Rot by XorNot on Wednesday June 11, 2014 @11:14AM (#7878402)

The design doesn't assume ECC RAM. It's recommended because you can't talk about end-to-end checksumming and then not explain that it can't proof you against unreliable memory.

All other filesystems are equally susceptible - if your memory is getting errors, they'll happily write those to disk too.

[ Parent | on HN ]

Re:HFS+ Bit Rot by rodgerd on Wednesday June 11, 2014 @06:59PM (#7880928)

Actually, XFS checksumming will alert on errors caused by bad RAM.

[ Parent | on HN ]

Re:HFS+ Bit Rot by XorNot on Wednesday June 11, 2014 @08:54PM (#7881277)

Depends what you mean by this. ZFS will alert if it reads data into ram that then doesn't match the checksum during verification.

But it can't prevent a bitflip of data in memory from getting written to disk before the checksum is calculated. Nor can it prevent data being bitflipped after its been verified and handed off to the application.

Which I'm pretty sure XFS can't do either.

[ Parent | on HN ]

Re:HFS+ Bit Rot by orkoden on Wednesday June 11, 2014 @12:03PM (#7878710)

Apple could just as well use HFS+ on iOS and ZFS on OS X until the hardware catches up.

[ Parent | on HN ]

Re:HFS+ Bit Rot by msbarnett on Wednesday June 11, 2014 @02:14PM (#7879494)

It's not just phones that have to catch up. The CPU and RAM requirements would wreak havoc on laptop battery life as well.

[ Parent | on HN ]