Hacker News new | past | comments | ask | show | jobs | submit login

How so? If anything, ignoring ZFS's cache subsystem, a filesystem is another module in a pluggable system if many fileystems. DTrace on the other hand to be most effective requires adding probes all over the kernel.



You're forgetting the weight of data and user practice for a mainstream project. Consider how those two scenarios would unfold:

Apple makes a mistake in 10.11.6 and ships a kernel without DTrace. Everything runs but a few nerds notice and file bug reports. 10.11.7 quietly ships and all is right with the world.

In contrast, shipping a new filesystem is enormously invasive: billions of hours are spent globally rewriting EVERY storage pool in existence. Some percentage of those will fail due to hardware problems or corruption which happened years ago (or even somewhere else) but was previously unnoticed, flooding support and the news with dire predictions. Every crash or performance issue noticed for the next year will probably be vocally blamed on the new filesystem, even if there are clear signs pointing elsewhere.

You don't want to deal with that any more than you have to.


Apple will _not_ remove the existing filesystems, and neither will they automatically migrate an existing HFS volume to APFS without first asking, especially not during an OS update. There are many filesystems in the kernel, and compared to DTrace probes, they are very minimally invasive. Adding DTrace probes means touching all kinds of places in the kernel, so it's definitely more invasive.


Again, look at it from the perspective of a user or system administrator rather than a kernel developer. Yes, someone has to remove a bunch of easily searched for and removed code and rerun their test suite but that's a handful of people for a very small amount of time compared to the number of people involved with something which will make a major change on hundreds of millions of running systems. More critically, the development work is completely under Apple's control and shipping can be delayed as long as it takes to complete testing but once they ship a filesystem it will very quickly reach the point where it will be in the wild for years even if they immediately ship a new release which takes a different direction.

The question isn't whether Apple will force this on users soon or without notice but rather the observation that they're going to be very careful not to do this more often than actually necessary. That's why despite having implemented and shipped ZFS in the 10.5 beta series they removed it prior to release. Sure, it might have gone okay but if that changed later there would be no easy way to go back without forcing users to migrate existing data and if that hit a licensing/patent case, the other side's lawyers enjoy the extra leverage which that would give them.

As an aside, “There are many filesystems in the kernel” is technically true but misleading: HFS+/HFSX is used constantly on every device, FAT/ExFAT are used regularly by many users, and everything else is a rounding error. A few Mac users use NFS or SMB, even fewer use UFS, etc. and no iOS device uses any of those.


I agree with most of that, but I don't understand why you think DTrace is less invasive than another filesystem. They could have shipped ZFS all along and only now declared it stable, if they wanted to. They also could have integrated it again, now that it's actually more portable than before due to OpenZFS. I don't use Macs, so I don't have a direct interest in ZFSonMac, but using a filesystem which can be accessed from Linux, illumos and FreeBSD has some practical aspects which are definitely missing with APFS. Someone will eventually, unless Apple prevents it with IP and Patents, implement APFS for BSD or Linux, but just as NTFS-3G, it will never be fully stable and reliable as a Mac version of OpenZFS could have been. Apple's own APFS implementation will be stable of course, and for other versions to be good as well, they would have to open source the critical bits.


I think the point is that if Apple had to remove DTrace for legal reasons, the impact to Apple's business and customers would be minimal. If a hypothetical AppleZFS shipped on a billion devices and then Apple lost a patent lawsuit, Apple would be totally screwed. A filesystem can't just be pulled out of the OS without shipping a new one and converting every device. Apple could potentially be in a position where they couldn't sell any new devices at all, and ZFS support in other OSes wouldn't help at all.


That's a fair point, and I'm sure Apple didn't integrate DTrace without checking the legal ramifications.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: