Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFS: Apple's new filesystem that wasn't (2016)

ahl.dtrace.org

Post reply on HN
Print view View original

141–150 of 209 posts

Re: ZFS: Apple's new filesystem that wasn't (2016)

#141

Post by cryptonector »

tw04 wrote: post #140
cryptonector wrote: post #131

Earlier quoted context omitted.

The NetApp lawsuit. Apple wanted indemnification, and Sun/Oracle did not want to indemnify Apple. At the time that NetApp filed its lawsuit I blogged about how ZFS was a straightforward evolution of BSD 4.4's log structured filesystem. I didn't know that to be the case historically, that is, I didn't know if Bonwick was inspired by LFS, but I showed how almost in every way ZFS was a simple evolution of LFS. I showed…

While I was disappointed that NetApp sued, the ZFS team literally referenced NetApp and WAFL multiple times in their presenations IIRC. They were kind of begging to be sued. Also, according to NetApp, "Sun started it". https://www.networkcomputing.com/data-center-networking/neta...

Ok? So what?

Re: ZFS: Apple's new filesystem that wasn't (2016)

#142

Post by cryptonector »

smittywerben wrote: post #22

Thanks for sharing I was just looking for what happened to Sun. I like the second-hand quote comparing the IBM and HP as "garbage trucks colliding" plus the inclusion of blog posts with links to the court filings. Is it fair to say ZFS made most sense on Solaris using Solaris Containers on SPARK?

> Is it fair to say ZFS made most sense on Solaris using Solaris Containers on SPARK?

You mean SPARC. And no, ZFS stands alone. But yes, containers were a lot faster to create using ZFS.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#143

Post by cryptonector »

jeroenhd wrote: post #11

I wonder what ZFS in the iPhone would've looked like. As far as I recall, the iPhone didn't have error correcting memory, and ZFS is notorious for corrupting itself when bit flips hit it and break the checksum on disk. ZFS' RAM-hungry nature would've also forced Apple to add more memory to their phone.

> ZFS is notorious for corrupting itself when bit flips hit it and break the checksum on disk.

If you have no mirrors and no raidz and no ditto blocks then errors cause problems, yes. Early on they would cause panics.

But this isn't ZFS "corrupting itself", rather, it's ZFS saving itself and you from corruption, and the price you pay for that is that you need to add redundancy (mirrors, raidz, or ditto blocks). It's not a bad deal. Some prefer not to know.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#144

Post by cryptonector »

throw0101b wrote: post #37

Apple and Sun couldn't agree on a 'support contract'. From Jeff Bonwick, one of the co-creators ZFS: >> Apple can currently just take the ZFS CDDL code and incorporate it (like they did with DTrace), but it may be that they wanted a "private license" from Sun (with appropriate technical support and indemnification), and the two entities couldn't come to mutually agreeable terms. > I cannot disclose details, but that…

> indemnification

That was the sticking point. In the context of the NetApp lawsuit Apple wanted indemnification should Sun/Oracle lose the suit.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#145

Post by UltraSane »

wkat4242 wrote: post #134
yjftsjthsd-h wrote: post #59

Earlier quoted context omitted.

> I find that most BSD users don't really care about such legalese and most people I know that run FreeBSD are running ZFS on root. I don't think it's that they don't care , it's that the CDDL and BSD-ish licenses are generally believed to just not have the conflict that CDDL and GPL might. (IANAL, make your own conclusions about whether either of those are true)

Hmm yeah but that's the thing, who really cares about licenses as a user? I certainly don't. It's just some stuff that some lawyers fuss over. I don't read EULAs either nor would I even consider obeying them. The whole civil-legal world is just something I ignore. I do have a feeling that Linux users in general care more about the GPL which is quite specific of course. Though I wonder if anyone chooses Linux for that…

I feel the same way. The way people talk about how ZFS is incompatible with Linux feels like debates over religious doctrine.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#147

Post by water9 »

TacticalCoder wrote: post #104
whartung wrote: post #63

As a desktop user, I am content with APFS. The only feature from ZFS that I would like, is the corruption detection. I honestly don't know how robust the image and video formats are to bit corruption. On the one hand, potentially, "very" robust. But on the other, I would think that there are some very special bits that if toggled can potentially "ruin" the entire file. But I don't know. However, I can say, every time…

> The only feature from ZFS that I would like, is the corruption detection. I run ZFS on my main server at home (Proxmox: a Linux hypervisor based on Debian and Proxmox ships with ZFS) but... No matter the FS, for "big" files that aren't supposed to change, I append a (partial) cryptographic checksum to the filename. For example: 20240238-familyTripBari.mp4 becomes 20240238-familyTripBari-b3-8d77e2419a36.mp4 where "-…

The checksum doesn’t help you fix the flipped bit nor does it tell you which bit flipped. You would have to re-create from a complete back up instead of using the efficiency of parity discs. Basically Raid 1 vs Raid 5

Re: ZFS: Apple's new filesystem that wasn't (2016)

#148

Post by water9 »

fweimer wrote: post #114
ryao wrote: post #66

Earlier quoted context omitted.

ZFS has ditto blocks that allows it to self heal in the case of corrupt metadata as long as a good copy remains (and there would be at least 2 copies by default). ZFS only ever needs you to restore from backup if the damage is so severe that there is no making sense of things. Minor things like the indirect blocks being missing for a regular file only affect that file. Major things like all 3 copies of the MOS (the e…

As far as I understand it, ditto blocks were only used if the corruption was detected due to checksum mismatch. If the checksum was correct, but metadata turned out to be unusable later (say because it was corrupted in memory, and the the checksum was computed after the corruption happened), that was treated as a fatal error.

So the solution is to use ._ files that most people will delete because they are a nuisance?

Re: ZFS: Apple's new filesystem that wasn't (2016)

#149

Post by krupan »

"Still another version I’ve heard calls into question the veracity of their purported friendship, and has Steve instead suggesting that Larry go f*ck himself. Normally the iconoclast, that would, if true, represent Steve’s most mainstream opinion."

LOL!!

I really hope they weren't friends, that really shatters my internal narrative (mainly because I can't actually picture either of them having actual friends).

Re: ZFS: Apple's new filesystem that wasn't (2016)

#150

Post by atoav »

ryao wrote: post #76
whartung wrote: post #63

As a desktop user, I am content with APFS. The only feature from ZFS that I would like, is the corruption detection. I honestly don't know how robust the image and video formats are to bit corruption. On the one hand, potentially, "very" robust. But on the other, I would think that there are some very special bits that if toggled can potentially "ruin" the entire file. But I don't know. However, I can say, every time…

> I honestly don't know how robust the image and video formats are to bit corruption. It depends on the format. A BMP image format would limit the damage to 1 pixel, while a JPEG could propagate the damage to potentially the entire image. There is an example of a bitflip damaging a picture here: https://arstechnica.com/information-technology/2014/01/bitro... That single bit flip ruined about half of the image. As for…

A thing that can destroy most files in terms of readability is a bit flip in the header section. These could be theoretically corrected with clever guesswork and a hex editor, but in practise it is going to be hard to know where the bit flip occured, when a file just can't be read anymore.
Post reply on HN