@Colin To be clear this is the same bug I originally hit and opened the launchpad for, it just doesn't quite match with what most people saw in the upstream bugs. But it seemed to get fixed anyway for a while, and has regressed again somehow.
Same exception as from the original description and others reporting:
2021 May 16 21:19:09 laptop VERIFY(0 == sa_handle_get_from_db(zfsvfs->z_os, db, zp, SA_HDL_SHARED, &zp->z_sa_hdl)) failed
The upstream bug mostly reported slightly different errors though similar symptoms (files get stuck and can't be accessed).
I also tried to use 'zdb' to check if incorrect file modes were saved, unfortunately it seems zdb does not work for encrypted datasets, it only dumps the unencrypted block info and doesn't dump info about filemodes etc from the encrypted part. So I can't check that.
I've reverted back to 5.11.0-25 for now and it's stable again.
@Colin To be clear this is the same bug I originally hit and opened the launchpad for, it just doesn't quite match with what most people saw in the upstream bugs. But it seemed to get fixed anyway for a while, and has regressed again somehow.
Same exception as from the original description and others reporting: get_from_ db(zfsvfs- >z_os, db, zp, SA_HDL_SHARED, &zp->z_sa_hdl)) failed
2021 May 16 21:19:09 laptop VERIFY(0 == sa_handle_
The upstream bug mostly reported slightly different errors though similar symptoms (files get stuck and can't be accessed).
I also tried to use 'zdb' to check if incorrect file modes were saved, unfortunately it seems zdb does not work for encrypted datasets, it only dumps the unencrypted block info and doesn't dump info about filemodes etc from the encrypted part. So I can't check that.
I've reverted back to 5.11.0-25 for now and it's stable again.