3 ms·

>How the heck did this ever make it through? Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's so they

>How the heck did this ever make it through? Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's so they weren't even able to hit this. >I don't think this ever would have happened pre-OpenZFS, and undermines the stable reputation of ZFS. Of course it happened pre-OpenZFS: https://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-running-oracle-on.html?m=1 https://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss... From the people that brought you Slowlaris. >OpenZFS needs to do better and look to FreeBSD developers, not Linux developers, as role models. This was introduced by a FreeBSD developer and was caught by a Linux one. You need to rethink your role models.

aforwardslash 3y ago
>Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's This is often regarded as a good thing in the BSD world. In all fairness, this bug just enforces that notion. And Solaris (at least on amd64) wasn't slow. It was demanding, and not really suited for desktop. And it was picky with hardware. Totally agree on the rest of your comment, though.
- Always_Anon 3y ago
  >This is often regarded as a good thing in the BSD world. In all fairness, this bug just enforces that notion. Same in Linux, which is why you'd choose a distro that's less bleeding edge. >And Solaris (at least on amd64) wasn't slow. No, it was slow. There's a reason why everyone in HPC/HFT/etc. moved off Solaris to Linux in the 2000s. Linux was regularly beating Slowlaris in practically every category at the end.
Squossifrage 3y ago
[flagged]
ryao 3y ago
>Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's so they weren't even able to hit this. Honestly, this feature could have used more testing on both platforms. Also, FreeBSD's VFS in theoretically able to support reflinks across datasets while Linux's VFS disallows that. It is not really behind.
- Always_Anon 3y ago
  >FreeBSD's VFS in theoretically able to support reflinks across datasets while Linux's VFS disallows that. I don't believe so, you're still not able to hardlink across file systems in BSD. >It is not really behind. It is behind: https://github.com/openzfs/zfs/issues/405 https://github.com/openzfs/zfs/issues/405

aforwardslash 3y ago

>Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's This is often regarded as a good thing in the BSD world. In all fairness, this bug just enforces that notion. And Solaris (at least on amd64) wasn't slow. It was demanding, and not really suited for desktop. And it was picky with hardware. Totally agree on the rest of your comment, though.

Always_Anon 3y ago
>This is often regarded as a good thing in the BSD world. In all fairness, this bug just enforces that notion. Same in Linux, which is why you'd choose a distro that's less bleeding edge. >And Solaris (at least on amd64) wasn't slow. No, it was slow. There's a reason why everyone in HPC/HFT/etc. moved off Solaris to Linux in the 2000s. Linux was regularly beating Slowlaris in practically every category at the end.

Squossifrage 3y ago

[flagged]

ryao 3y ago

>Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's so they weren't even able to hit this. Honestly, this feature could have used more testing on both platforms. Also, FreeBSD's VFS in theoretically able to support reflinks across datasets while Linux's VFS disallows that. It is not really behind.

Always_Anon 3y ago
>FreeBSD's VFS in theoretically able to support reflinks across datasets while Linux's VFS disallows that. I don't believe so, you're still not able to hardlink across file systems in BSD. >It is not really behind. It is behind: https://github.com/openzfs/zfs/issues/405 https://github.com/openzfs/zfs/issues/405