[Linux-cluster] GFS2 filesystem consistency error

[Daniel Dehennin]

Bob Peterson <rpeterso at redhat.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20160215/1403e56d/attachment.sig>