Two new versions of OpenZFS fix long-hidden corruption bug

The bug that was very occasionally corrupting data on file copies in OpenZFS 2.2.0 has been identified and fixed, and there's a fix for the previous OpenZFS release too. The OpenZFS development team have put out not one but two new releases of the open-source cross-platform filesystem for Linux and FreeBSD. Version 2.2.2 fixes …

[DougMac]

coreutils 9 isn't part of the problem, it just allows an easier way to trigger the bug in ZFS.

There were other programs that dealt with sparse files that triggered the problem in the past that didn't involve coreutils.

[eldakka]

> There were other programs that dealt with sparse files that triggered the problem in the past that didn't involve coreutils.

Right, but those were usually relatively specialised and/or niche programs.

The specific program within the Coreutils 9 package that triggers this bug is a rather non-speciialised, non-niche program - cp.

That is, Coreutils 9 updated the core 'cp' command - as bog standard a unix/linux command as you can get, the copy file command - in a fashion that can trigger this bug.

[PRR]

> – long stretches of zeroes – called the SEEK_HOLE optimization.

So can we say that OpenZFS can't copy nothing right?

[theOtherJT]

Scary for those with big scientific data sets...

...if this bug has been kicking around unnoticed for that long. If the changes to cp just made it more common for the bug to be triggered but it was always there, there are possibly god knows how many much rarer cases that have been silently corrupting files for years and no one ever noticed.