Hi Guillaume,
On Mon, Mar 18, 2013 at 08:51:17PM +0100, Guillaume Anciaux wrote:
> On 18/03/2013 17:47, Ben Myers wrote:
> >On Mon, Mar 18, 2013 at 02:59:56AM -0700, anciaux wrote:
> >>I have been struggling to repair a partition after a RAID disk set failure.
> >>
> >>Apparently the data is accessible with no problem since I can mount the
> >>partition.
> >>
> >>The problem is ONLY when I use the uquota and gquota mount option (which I
> >>was using freely before the disk failure).
...
> >>I fear for the filesystem to be corrupted and xfs_repair not able to
> >>notice. At least for the quota information. Someone has any hint on
> >>what could be the problem ?
> >
> >Have you tried xfs_repair? I'm not clear on that.
>
> Sorry I was not clear enough in my message: Yes I did hit xfs_repair
> -L. And it permitted me to mount the partition but ONLYwhen quota
> options are not set. If quota is activated then a corruption message
> (see below for the complete message) is printed in syslog.
Running xfs_repair with the -L option will have zeroed the log so you have
likely lost some recent metadata transactions. -L is dangerous.
> >>On how I could fix/regenerate the quota
> >>information ?
> >
> >It looks like you're hitting the corruption during quotacheck, which is in the
> >process of regenerating the quota information. Your paste seems to be missing
> >the output that would be printed by xfs_warn at line 513 which would include
> >ino, total nextents, and the number of blocks used. Is that info available?
>
> Sorry I did a " | grep -i xfs" for the previous log. The complete
> log is hereafter:
>
> Mar 18 09:35:50 storage kernel: [ 417.883817] XFS (sdb1): corrupt
> dinode 3224608213, extent total = 1, nblocks = 0.
^^^^^^^^^^
You know the inode number now. It has one extent. It is using 0 blocks which
is why you're having trouble. You could use 'find' to find that file.
> Corruption detected. Unmount and run xfs_repair
Does a subsequent xfs_repair (without -L) find the inode and fix it? If not we
have a bug in xfs_repair. I recommend you try with the latest and greatest
version which you can find here: git://oss.sgi.com/xfs/cmds/xfsprogs.git
> >Could you provide a metadump? This bug report isn't ringing any bells for me
> >yet, but maybe it will for someone else.
>
> I wish I could do this but the result of "meta_dump /dev/sdb1" for
> the partition containing 6.9T of data is promising to be quite
> large. Are there special options I should use to extract only the
> information that you would need to investigate my problem ?
A metadump is the best option. How big?
Thanks,
Ben
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
