Bob Peterson <rpeterso@xxxxxxxxxx> writes:
[...]
> As Steve mentioned, this means it tried to free a block that was already free.
> The problem might be due to timing issues with regard to changing blocks
> from "unlinked" state to "free" state. I have a number of patches required
> to fix this, but some of them are not even in the upstream kernel yet.
> And there is no guarantee this is the cause or solution for your
> problem.
Ok, I understand.
> As for fixing the file system: Newer versions of fsck.gfs2 should be able to
> fix the file system. If it doesn't fix the file system, perhaps I could
> get a copy of your file system metadata (via "gfs2_edit savemeta") and I
> can see where it's failing. There are some known problems with fsck.gfs2 not
> being able to correctly repair file systems that have been grown with gfs2_grow.
> I've got fixes for that too, but it is all experimental code and none have gone
> upstream yet. Your metadata might help me test it. :)
It's running but looks like it will take a long time and produce a huge
file.
But the start of the “gfs2_edit savemeta” command looks stange to me:
There are 1073479680 blocks of 4096 bytes in the destination device.
Reading resource groups...Done. File system size: 1023.734M
Is it saying my FS is 1TB instead of the real 4TB?
Regards.
--
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF
Attachment:
signature.asc
Description: PGP signature
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
