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

161–170 of 209 posts

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

#161

Post by porjo »

ahl wrote: post #51
secabeen wrote: post #47

ZFS remains an excellent filesystem for bulk storage on rust, but were I Apple at the time, I would probably want to focus on something built for the coming era of flash and NVMe storage. There are a number of axioms built into ZFS that come out of the spinning disk era that still hold it back for flash-only filesystems.

Certainly one would build something different starting in 2025 rather than 2001, but do you have specific examples of how ZFS’s design holds it back? I think it has been adapted extremely well for the changing ecosystem.

This presentation from 2022 covers the topic: https://m.youtube.com/watch?v=v8sl8gj9UnA

Note: sound drops out for a couple minutes at 1:30 mark but comes back.

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

#162

Post by CTDOCodebases »

water9 wrote: post #147
TacticalCoder wrote: post #104

Earlier quoted context omitted.

> 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

If OP is backing up locally onto a ZFS server like they said they were then say propagating this data to a cloud provider like Blackblaze which uses ext4 this sort of approach makes sense.

This approach is also good when you have multiple sources to restore from. It makes it easier to determine what is the new "source of truth."

Theres something to be said too for backing up onto different FS too. You don't want to be stung by a FS bug and if you do then it's good to know about it.

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

#163

Post by rollcat »

water9 wrote: post #147
TacticalCoder wrote: post #104

Earlier quoted context omitted.

> 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

I wonder how hard would it be to detect which single bit was flipped? As ryao noted, in JPEGs it's immediately obvious where the image was corrupted - by visual inspection. Similar for videos, you only need to inspect the data following a single I-frame. Even for bitmap/text files, you could just scan the entire file, try flipping one bit at a time, and compare the result with the checksum.

Unlike e.g. KDFs, checksums are built to be performant, so that verifying one is a relatively fast operation. The Blake family is about 8 cycles per byte[1], I guess a modern CPU could do [napkin math] some 500-1000 MB per second? Perhaps I'm off by an order of magnitude or two, but if the file in question is precious enough, maybe that's worth a shot?

[1]: https://en.wikipedia.org/wiki/BLAKE_(hash_function)

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

#164

Post by teruakohatu »

pseudalopex wrote: post #106
ryao wrote: post #62

Earlier quoted context omitted.

The ZFS driver will release memory if the kernel requests it. The only integration level issue is that the free command does not show ARC as a buffer/cache, so it misrepresents reality, but as far as I know, this is an issue with caches used by various filesystems (e.g. extent caches). It is only obvious in the case of ZFS because the ARC can be so large. That is a feature, not a bug, since unused memory is wasted me…

> The ZFS driver will release memory if the kernel requests it. Not fast enough always.

You were downvoted but I have also run into situations where it didn’t and caused a cascade of processes getting out of memory errors. In both instances I was pushing the server beyond what was reasonable.

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

#165

Post by ryao »

atoav wrote: post #150
ryao wrote: post #76

Earlier quoted context omitted.

> 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.

Good catch. I had omitted that since I was not familiar with the low level details of the file formats (e.g. would a video file duplicate that data throughout it for enabling live streaming), but if the file only has one copy of important information (e.g. I-frame spacing, dimensions) and that gets corrupted, boom.

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

#166

Post by nar001 »

crossroadsguy wrote: post #159
krupan wrote: post #149

"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).

[flagged]

That's exactly why so many of these can't be friends with each other though, they clash, they always have to be the most important person in the room

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

#167

Post by gruturo »

wkat4242 wrote: post #136
gruturo wrote: post #98

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. What a weird take. BSD's license is compatible with ZFS, that's why. "Don't really care?" Really? Come on.

I just mean that GPL is a bit of a religion. There are very strong opinions and principles behind it. Whereas the BSD license is more like "do whatever you want". It makes sense that the followers of the former care more deeply about it, right? Personally I don't care about or obey any software licenses, as a user. But this is kinda the vibe I get from other BSD users if a license discussion comes up. Maybe it's my b…

I get what you mean and probably there are people like that, but I consider it mostly an exaggeration.

Simply - the GPL has some clauses enforcing some obligations (to prevent some rights from being taken away from you, the end user - according to their wording, and I agree), these and other clauses make it legally incompatible with the inclusion of ZFS (CDDL license) in the Linux kernel (GPL). You can build it yourself (so indeed as a user you get to not care or obey) but not distribute it (this is the problem of your distribution's maintainer).

Canonical's lawyers think this is not a problem if the ZFS code is distributed as a module, instead of compiled into the kernel itself, and since 2016 Ubuntu shipped with ZFS support.

The BSD license is considered perfectly compatible with the inclusion of CDDL licensed code and therefore many BSD distros ship with ZFS (and Dtrace) out of the box without legal worries. Indeed Oracle hasn't come knocking.

TL;DR: it's not a vibe. Some licenses are compatible with each other, some aren't. It also depends on how different licenses come into play into a "finished product" (e.g. kernel module vs monolithic build)

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

#168

Post by tw04 »

bcantrill wrote: post #154
tw04 wrote: post #140

Earlier quoted context omitted.

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...

No, the ZFS team did not "literally reference NetApp and WAFL" in their presentations and no, Sun did not "start it" -- NetApp initiated the litigation (though Sun absolutely countersued), and NetApp were well on their way to losing not only their case but also their WAFL patents when Oracle acquired Sun. Despite having inherited a winning case, Oracle chose to allow the suit to be dismissed[0]; terms of the settleme…

We can agree to disagree.

Your own link states that Sun approached NetApp about patents 18 months prior to the lawsuit being filed (to be clear that was Storagetek before Sun acquired them):

>The suit was filed in September 2007, in Texas, three years ago, but the spat between the two started 18 months before that, according to NetApp, when Sun's lawyers contacted NetApp saying its products violated Sun patents, and requesting licensing agreements and royalties for the technologies concerned.

And there was a copy of the original email from the lawyer which I sadly did not save a copy of, as referenced here:

https://ntptest.typepad.com/dave/2007/09/sun-patent-team.htm...

As for the presentation, I can't find it at the moment but will keep looking because I do remember it. That being said, a blog post from Val at the time specifically mentions NetApp, WAFL, how the team thought it was cool and decided to build your own:

https://web.archive.org/web/20051231160415/http://blogs.sun....

And the original paper on ZFS that appears to have been scrubbed from the internet mentions WAFL repeatedly (and you were a co-author so I'm not sure why you're saying you didn't reference NetApp or WAFL):

https://ntptest.typepad.com/dave/2007/09/netapp-sues-sun.htm...

https://www.academia.edu/20291242/Zfs_overview

>The file system that has come closest to our design principles, other than ZFS itself,is WAFL[8],the file system used internally by Network Appliance’s NFS server appliances.

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

#169

Post by tw04 »

ahl wrote: post #155
tw04 wrote: post #140

Earlier quoted context omitted.

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...

Seems specious. Patents don't preclude one from overtly trying to compete; they protect specific mechanisms. In this case either ZFS didn't use the same mechanisms or the mechanisms themselves were found to have prior art.

Whether the claims were valid or not I guess we'll never know given Oracle and NetApp decided to settle.

What I DO knows is that if the non-infringement were as open and shut as you and Bryan are suggesting, Apple probably wouldn't have scrapped years of effort and likely millions in R&D for no reason. It's not like they couldn't afford some lawyers to defend a frivelous lawsuit...

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

#170

Post by ahl »

tw04 wrote: post #169
ahl wrote: post #155

Earlier quoted context omitted.

Seems specious. Patents don't preclude one from overtly trying to compete; they protect specific mechanisms. In this case either ZFS didn't use the same mechanisms or the mechanisms themselves were found to have prior art.

Whether the claims were valid or not I guess we'll never know given Oracle and NetApp decided to settle. What I DO knows is that if the non-infringement were as open and shut as you and Bryan are suggesting, Apple probably wouldn't have scrapped years of effort and likely millions in R&D for no reason. It's not like they couldn't afford some lawyers to defend a frivelous lawsuit...

Maybe! Bryan and I were pretty close to the case and to the implementation of ZFS. But maybe Apple did detect some smoking gun of which somehow we were unaware. I (still) think Jonathan’s preannouncement was the catalyst for Apple changing direction.
Post reply on HN