Problem with xfs_repair

Problem with xfs_repair

[Ralf Hildebrandt]

xfs_repair gave me this when repairing my / fs using a knoppix boot cd:

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - marking entry "lost+found" to be deleted
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ... 
rebuilding directory inode 128

fatal error -- can't read block 16777216 for directory inode 167785633

a) How can I find out which file/directory this inode belongs to?
b) Can I mark the block defektiv somehow?

-- 
Ralf Hildebrandt (i.A. des IT-Zentrums)         Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin            Tel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin    Fax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF                 send no mail to spamtrap@charite.de

RE: Problem with xfs_repair

[Barry Naujok]

Hi Ralf, 

> -----Original Message-----
> From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] 
> On Behalf Of Ralf Hildebrandt
> Sent: Friday, 28 July 2006 4:45 PM
> To: xfs@oss.sgi.com
> Subject: Problem with xfs_repair
> 
> xfs_repair gave me this when repairing my / fs using a 
> knoppix boot cd:
> 
> Phase 1 - find and verify superblock...
 [snip]
> 
> fatal error -- can't read block 16777216 for directory inode 167785633
> 
> a) How can I find out which file/directory this inode belongs to?
> b) Can I mark the block defektiv somehow?

You have hit a recent regression that is covered in the FAQ http://oss.sgi.com/projects/xfs/faq.html#dir2

You have two options:
  1. Do the steps in the FAQ
  2. Try the xfs_repair patch I just posted to this list.

Re: Problem with xfs_repair

[Ralf Hildebrandt]

* Barry Naujok <bnaujok@melbourne.sgi.com>:
 
> You have hit a recent regression that is covered in the FAQ http://oss.sgi.com/projects/xfs/faq.html#dir2

I was only aware of a bug in 2.6.18-rcX (until now). Thanks.
I'm in fact running 2.6.17.7
 
> You have two options:
>   1. Do the steps in the FAQ

Just what I asked for.

>   2. Try the xfs_repair patch I just posted to this list.

This means I'd have to get this running under knoppix (or should I try
an in place repair)?

-- 
Ralf Hildebrandt (i.A. des IT-Zentrums)         Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin            Tel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin    Fax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF                 send no mail to spamtrap@charite.de

Re: Problem with xfs_repair

[Justin Piszcz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2407 bytes --]



On Fri, 28 Jul 2006, Ralf Hildebrandt wrote:

> xfs_repair gave me this when repairing my / fs using a knoppix boot cd:
>
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>        - zero log...
>        - scan filesystem freespace and inode maps...
>        - found root inode chunk
> Phase 3 - for each AG...
>        - scan and clear agi unlinked lists...
>        - process known inodes and perform inode discovery...
>        - agno = 0
>        - agno = 1
>        - agno = 2
>        - agno = 3
>        - agno = 4
>        - agno = 5
>        - agno = 6
>        - agno = 7
>        - agno = 8
>        - agno = 9
>        - agno = 10
>        - agno = 11
>        - agno = 12
>        - agno = 13
>        - agno = 14
>        - agno = 15
>        - process newly discovered inodes...
> Phase 4 - check for duplicate blocks...
>        - setting up duplicate extent list...
>        - clear lost+found (if it exists) ...
>        - clearing existing "lost+found" inode
>        - marking entry "lost+found" to be deleted
>        - check for inodes claiming duplicate blocks...
>        - agno = 0
>        - agno = 1
>        - agno = 2
>        - agno = 3
>        - agno = 4
>        - agno = 5
>        - agno = 6
>        - agno = 7
>        - agno = 8
>        - agno = 9
>        - agno = 10
>        - agno = 11
>        - agno = 12
>        - agno = 13
>        - agno = 14
>        - agno = 15
> Phase 5 - rebuild AG headers and trees...
>        - reset superblock...
> Phase 6 - check inode connectivity...
>        - resetting contents of realtime bitmap and summary inodes
>        - ensuring existence of lost+found directory
>        - traversing filesystem starting at / ...
> rebuilding directory inode 128
>
> fatal error -- can't read block 16777216 for directory inode 167785633
>
> a) How can I find out which file/directory this inode belongs to?
> b) Can I mark the block defektiv somehow?
>
> -- 
> Ralf Hildebrandt (i.A. des IT-Zentrums)         Ralf.Hildebrandt@charite.de
> Charite - Universitätsmedizin Berlin            Tel.  +49 (0)30-450 570-155
> Gemeinsame Einrichtung von FU- und HU-Berlin    Fax.  +49 (0)30-450 570-962
> IT-Zentrum Standort CBF                 send no mail to spamtrap@charite.de
>
>

Is your knoppix boot cd 5.0.1 == 2.6.17 == bugged kernel? ;P

Re: Problem with xfs_repair

[Justin Piszcz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed, Size: 2628 bytes --]



On Fri, 28 Jul 2006, Justin Piszcz wrote:

>
>
> On Fri, 28 Jul 2006, Ralf Hildebrandt wrote:
>
>> xfs_repair gave me this when repairing my / fs using a knoppix boot cd:
>> 
>> Phase 1 - find and verify superblock...
>> Phase 2 - using internal log
>>        - zero log...
>>        - scan filesystem freespace and inode maps...
>>        - found root inode chunk
>> Phase 3 - for each AG...
>>        - scan and clear agi unlinked lists...
>>        - process known inodes and perform inode discovery...
>>        - agno = 0
>>        - agno = 1
>>        - agno = 2
>>        - agno = 3
>>        - agno = 4
>>        - agno = 5
>>        - agno = 6
>>        - agno = 7
>>        - agno = 8
>>        - agno = 9
>>        - agno = 10
>>        - agno = 11
>>        - agno = 12
>>        - agno = 13
>>        - agno = 14
>>        - agno = 15
>>        - process newly discovered inodes...
>> Phase 4 - check for duplicate blocks...
>>        - setting up duplicate extent list...
>>        - clear lost+found (if it exists) ...
>>        - clearing existing "lost+found" inode
>>        - marking entry "lost+found" to be deleted
>>        - check for inodes claiming duplicate blocks...
>>        - agno = 0
>>        - agno = 1
>>        - agno = 2
>>        - agno = 3
>>        - agno = 4
>>        - agno = 5
>>        - agno = 6
>>        - agno = 7
>>        - agno = 8
>>        - agno = 9
>>        - agno = 10
>>        - agno = 11
>>        - agno = 12
>>        - agno = 13
>>        - agno = 14
>>        - agno = 15
>> Phase 5 - rebuild AG headers and trees...
>>        - reset superblock...
>> Phase 6 - check inode connectivity...
>>        - resetting contents of realtime bitmap and summary inodes
>>        - ensuring existence of lost+found directory
>>        - traversing filesystem starting at / ...
>> rebuilding directory inode 128
>> 
>> fatal error -- can't read block 16777216 for directory inode 167785633
>> 
>> a) How can I find out which file/directory this inode belongs to?
>> b) Can I mark the block defektiv somehow?
>> 
>> -- 
>> Ralf Hildebrandt (i.A. des IT-Zentrums)         Ralf.Hildebrandt@charite.de
>> Charite - Universitätsmedizin Berlin            Tel.  +49 (0)30-450 570-155
>> Gemeinsame Einrichtung von FU- und HU-Berlin    Fax.  +49 (0)30-450 570-962
>> IT-Zentrum Standort CBF                 send no mail to spamtrap@charite.de
>> 
>> 
>
> Is your knoppix boot cd 5.0.1 == 2.6.17 == bugged kernel? ;P

When repairing, do not use knoppix 5.0.1 or any version that uses 2.6.17 
either..

Re: Problem with xfs_repair

[Martin Steigerwald]

Am Freitag 28 Juli 2006 10:29 schrieb Ralf Hildebrandt:

> >   2. Try the xfs_repair patch I just posted to this list.
>
> This means I'd have to get this running under knoppix (or should I try
> an in place repair)?

Hello Ralf,

its possible to compile xfs_repair under Knoppix V5. I did it once. I do 
not remember the exact steps anymore. I needed uuid lib from ext3-utils 
as documented and I think some additional packages.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: Problem with xfs_repair

[Martin Steigerwald]

Am Freitag 28 Juli 2006 16:23 schrieb Justin Piszcz:

> > Is your knoppix boot cd 5.0.1 == 2.6.17 == bugged kernel? ;P
>
> When repairing, do not use knoppix 5.0.1 or any version that uses
> 2.6.17 either..

Hello Justin,

since xfs_repair works independently of the in-kernel XFS implementation 
it is possible to repair a directory-corruption broken XFS filesystem 
with Knoppix 5.0.1.

It did so already. I used 5.0.1 to rsync a workstation image and sure it 
had this slight corruption afterwards. Thus I xfs_repair'ed it and 
xfs_check'ed it afterwards and all was well again.

No this is not a recommendation to use Knoppix 5.0.1 to rsync an 
workstation image ;), but an xfs_repair should be possible (unless one 
hits the unfixable bug). 

Important: When XFS needs to be mounted first before repair in order to 
clean the log it might not be wise to use Knoppix 5.0.1 tough.

BTW when using Knoppix 5 or even an older version instead I recommend 
switching off the write cache to be on the safe side (hdparm -W0).

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7