You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I read that you are looking for battle testing filesystem recovery capabilities.
I want to suggest you one scenario that is very capable in corrupting filesystems in usually hard to recover ways.
I already destroyed in that way few systems while doing poor's man KVM: in system that do not offer any ipmi not kvm functionality but allows to boot some recovery os.
I mounted filesystem to fix some boot issues and then forgot to unmnount before running qemu with raw disk access to see if boot issue is resolved.
I believe if your implementation will be able to recover from such corruption you can assume your self healing is in very good shape (better than zfs).
I'm aware this might be considered unrealistic scenario to support or test against in that case feel free to ignore this and close the issue.
The text was updated successfully, but these errors were encountered:
I read that you are looking for battle testing filesystem recovery capabilities.
I want to suggest you one scenario that is very capable in corrupting filesystems in usually hard to recover ways.
I already destroyed in that way few systems while doing poor's man KVM: in system that do not offer any ipmi not kvm functionality but allows to boot some recovery os.
I mounted filesystem to fix some boot issues and then forgot to unmnount before running qemu with raw disk access to see if boot issue is resolved.
I believe if your implementation will be able to recover from such corruption you can assume your self healing is in very good shape (better than zfs).
I'm aware this might be considered unrealistic scenario to support or test against in that case feel free to ignore this and close the issue.
The text was updated successfully, but these errors were encountered: