Gregor Kopka
Gregor Kopka
@rmader I can reproduce the issue in a x11 session. What I found is that Clipboard Indicator seems to trigger (or cause?) what's described in https://gitlab.gnome.org/GNOME/mutter/issues/919#note_739406 in a quite boolean...
@rmader Yes, I'm one release behind on gtk+. It also might be that it's that other issue in mutter, but in that case... why does the issue only surface while...
The check of the supplied data would be implicit, as a successful repair could only happen in case the still existing on-disk checksum matches the file contents. I honestly don't...
@rincebrain Metadata is always redundant (at least one more copy than the data has), so a defect there is less likely, also it would lead to a defect that can...
>Limiting the repair functionality to **level 0 data blocks** would also be a good idea for safety. Sorry? Do you have a link toward some information about data block levels,...
> The specific concern is that because ZFS will trust the block contents as long as the checksum matches, we shouldn't allow it to overwrite any internal metadata. Yes. I...
@aletus You understand correctly, as long as there is redundancy (_either_ from the vdev being a mirror/raidz _or_ from ZFS maintaining one more `copies` of metadata than it does for...
> I've implemented a corruption healing zfs receive, see #9372 Thank you for your work.
Why is the stale bot still operating on issues marked as 'defect' ?
> I think the zfs rename's error message > might be more useful if it suggested to use the `-u` parameter I think that `zfs rename` should not try to...