On Sat, Mar 06, 2021 at 11:07:53PM -0500, Theodore Ts'o wrote:
> 1. e2image -r rbd13.e2i.qcow2 /tmp/rbd13
> 2. truncate -s 10T /tmp/rbd13
> 3. e2fsck -fy /tmp/rbd13
> 4. resize2fs /tmp/rbd13
> 5. e2fsck -fy /tmp/rbd13
> <note fs corruption>
(FTR: the report specified these instructions almost exactly
(the first fsck step is noted as optional,
since the corruption happened regardless thereof))> The bug report was also incorrect by saying that resizing the file > system to 4T was sufficient; that is not true. I must've conflated the results during testing somehow, apologies. > I suppose we can add some "are you sure? ARE YOU REALLY SURE?" > question to "tune2fs -f -E clear_mmp", [...] > Another workaround is to simply do an online resize (that is, on the > node where the file system is mounted, run resize2fs on the mounted > file system). This was all performed on a snapshot, which by definition is not mounted on any node, even if it had been when snapped. Indeed, there was no possibility of another node in my local non-ceph testing, purely because it was a local, unexported zvol, and I'm rather sure it wasn't mounted at any point when e2fsck/resize2fs were running, hence why I obliged to clearing the MMP in the first place. I've tried the patches and they appear to work pefectly, and I can no longer trigger this in any configuration in either environment. Thanks! наб
signature.asc
Description: PGP signature
