Re: GFS2 filesystem consistency error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux