4 ms·

I suggest completely backing out the code in question and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. metadata are not files

I suggest completely backing out the code in question and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. metadata are not files so they have no business going into lost+found.

deleted 9y ago
[deleted]
ryao 9y ago
> I suggest completely backing out the code in question This makes sense and we did that. It does not fix the fact that datasets exist where directories have incorrect sizes and files are orphaned because of the bad patch. > and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. While those are fine choices, they are not immune to bugs either. We had a space map corruption bug that we inherited from Illumos several years ago. We also inherited an issue in send/recv from illumos several years ago when hole_birth was introduced. FreeBSD’s TRIM implementation was far from perfect too and likely messed some things up given the long history of bug fixes that it required. I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. While they do a good job too, they are not infallible. The major OpenZFS platforms are roughly at parity in terms of their risk for bugs and regressions. > metadata are not files so they have no business going into lost+found. This makes no sense. How are orphaned files “metadata”? Why should they not be placed in a lost+found directory?
- Annatar 9y ago
  I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher than on BSD or illumos based operating systems, and to me, quality and stability are the most important things. For me a computer is a tool to make money and so reliability of hardware and especially the software trumps everything else. In fact, apart from reliability and simplicity nothing else is important to me when it comes to software.
  - monetus 9y ago
    Your postings reminded me of illumOS's existence, so I went looking for an arm build to no avail. You wouldn't happen to know if that is something that is available would you?
    - Annatar 9y ago
      https://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up https://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-... that's the closest you're going to get right now, unless you jump in and help out.
      - monetus 9y ago
        Thank you
  - pbarnes_1 9y ago
    [citation needed]
    - Annatar 9y ago
      How can one cite one's professional experience? But okay: bugzilla.redhat.com. Take a look at priority 1 bugs for epic breakage.

deleted 9y ago

[deleted]

ryao 9y ago

> I suggest completely backing out the code in question This makes sense and we did that. It does not fix the fact that datasets exist where directories have incorrect sizes and files are orphaned because of the bad patch. > and using a FreeBSD or an illumos based system like SmartOS. That's what I suggest. While those are fine choices, they are not immune to bugs either. We had a space map corruption bug that we inherited from Illumos several years ago. We also inherited an issue in send/recv from illumos several years ago when hole_birth was introduced. FreeBSD’s TRIM implementation was far from perfect too and likely messed some things up given the long history of bug fixes that it required. I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. While they do a good job too, they are not infallible. The major OpenZFS platforms are roughly at parity in terms of their risk for bugs and regressions. > metadata are not files so they have no business going into lost+found. This makes no sense. How are orphaned files “metadata”? Why should they not be placed in a lost+found directory?

Annatar 9y ago
I do not mean to discourage people from using those systems, but it is silly to adopt them because a bug got past joint OpenZFS review and landed in the Linux port first. That’s your opinion and while I extremely disagree with it, it is what it is. It might be even true in the case if ZFS on Linux team but on the whole of GNU/Linux, my professional experience is that the amount of bugs and breakage is much higher than on BSD or illumos based operating systems, and to me, quality and stability are the most important things. For me a computer is a tool to make money and so reliability of hardware and especially the software trumps everything else. In fact, apart from reliability and simplicity nothing else is important to me when it comes to software.
- monetus 9y ago
  Your postings reminded me of illumOS's existence, so I went looking for an arm build to no avail. You wouldn't happen to know if that is something that is available would you?
  - Annatar 9y ago
    https://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up https://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-... that's the closest you're going to get right now, unless you jump in and help out.
    - monetus 9y ago
      Thank you
- pbarnes_1 9y ago
  [citation needed]
  - Annatar 9y ago
    How can one cite one's professional experience? But okay: bugzilla.redhat.com. Take a look at priority 1 bugs for epic breakage.