Successful with xfs_repair 3.1.9. Thanks!
All data are in lost+found, But before the xfs_repair, it was already the case.
A probable consequence of the original problem.
Philippe
________________________________________
De : Dave Chinner [david@xxxxxxxxxxxxx]
Date d'envoi : vendredi 30 janvier 2015 06:52
À : SCHEFFER, Philippe
Cc : xfs@xxxxxxxxxxx
Objet : Re: RE : xfs_repair fails with corrupt dinode
On Fri, Jan 30, 2015 at 01:42:07AM +0100, SCHEFFER, Philippe wrote:
> xfs_repair -p log in attached file.
>
> Philippe
> ________________________________________
> De : Dave Chinner [david@xxxxxxxxxxxxx]
> Date d'envoi : vendredi 30 janvier 2015 00:15
> À : SCHEFFER, Philippe
> Cc : xfs@xxxxxxxxxxx
> Objet : Re: xfs_repair fails with corrupt dinode
>
> On Thu, Jan 29, 2015 at 04:48:15PM +0100, SCHEFFER, Philippe wrote:
> > Hi,
> >
> > I have a corrupted xfs filesytem. When I try to repair I get this error :
> > disconnected inode 1427919, moving to lost+found
> > corrupt dinode 1427919, extent total = 1, nblocks = 0. This is a bug.
> > Please capture the filesystem metadata with xfs_metadump and
> > report it to xfs@xxxxxxxxxxx.
> > cache_node_purge: refcount was 1, not zero (node=0x1f6c19620)
> >
> > fatal error -- 117 - couldn't iget disconnected inode
> >
> > I captured metada with xfs_metadump but the file is 1,4Gb long. I can't send it to you.
> >
> > I printed inode1427919 :
> >
> > xfs_db> inode 1427919
> > xfs_db> print
> > core.magic = 0x494e
> ....
> > core.format = 2 (extents)
> ....
> > core.size = 2536
> > core.nblocks = 1
> > core.extsize = 0
> > core.nextents = 1
> ....
> > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,320660992,1,0]
>
> That's an inode with one extent of one block and looks perfectly
> valid. We'll need the entire output of the xfs_repair run to see if
> there were any prior actions taken on that inode by xfs_repair....
As i pointed out to Brian on IRC earlier:
data fork in regular inode 1427919 claims used block 320660992
correcting nblocks for inode 1427919, was 1 - counted 0
So it looks like the inode has a cross linked block, repair dropped
the block count by that one block, and then failed to remove the
extent from the inode. So, a repair bug, that was...
commit e1f43b4c701b24d9b5bc85df858a8c36f0f0723b
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu Feb 2 07:39:10 2012 -0500
repair: update extent count after zapping duplicate blocks
When we find a duplicate extent in an extern format inode we do not zap
the whole inode, but just truncate it to the point where the duplicate
extent was found. But the current code only updates di_nblocks for the
new size, but no di_nextents/di_anextents. In most cases this isn't noticed,
but when moving such an inode to the lost+found directoy the consistency
check in xfs_iformat trips over it. Fix this by updating the on-disk
extent count as part of the inode repair.
Note that we zap btree format inodes with duplicate block completely
at this point, so this fix doesn't apply to them.
Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
Reported-by: Arkadiusz Mi??kiewicz <arekm@xxxxxxxx>
Tested-by: Arkadiusz Mi??kiewicz <arekm@xxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
.... fixed the 3 years ago. Upgrade your xfsprogs package and the
problem should go away.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
