3 ms·

It seems that this doesn't really fixe the bug [0] and also enables another one [1][2] [0] https://github.com/openzfs/zfs/issues/15526#issuecomment-1826125014

• veidr 3y ago
  (>_<) Oh man, I knew about [0] when I posted (which is why I said it just reduces the chance of hitting the bug (by a lot)). But after spending all Saturday JST on it, I went to bed before [1] was posted. Skimming through #6958 though, it seems like it's the lesser of evils, compared to #15526... I think? It's less obvious (to me) what the impact of #6958 is. Is it silent undetectable corruption of your precious data potentially over years, or more likely to cause a crash or runtime error? Reports like https://github.com/intel/bmap-tools/issues/65 https://github.com/intel/bmap-tools/issues/65 make it seem more like the latter. But I have to read more. But since the zfs_dmu_offset_next_sync setting was disabled by default until recently, I still suspect (but yeah, don't know for sure) that disabling is the safest thing we can currently do on unmodified ZFS systems.