Skip to contentSkip to conversation

Problem with xfs_repair

DISCUSSION Ralf Hildebrandt 4 participants 7 messages Jul 28, 2006 – Jul 29, 2006

lore
Share & tools
lore

Ralf Hildebrandt

author
#0 lore raw

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?

Signature · 4 lines
Ralf Hildebrandt (i.A. des IT-Zentrums)         [email protected]
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 [email protected]
#1 lore raw

Hi Ralf,

Quoted 11 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ralf Hildebrandt
Sent: Friday, 28 July 2006 4:45 PM
To: [email protected]
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]

Quoted 5 lines

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.

author
#2 lore raw

* Barry Naujok <[email protected]>:

Quoted 1 line

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

Quoted 2 lines

You have two options:
1. Do the steps in the FAQ

Just what I asked for.

Quoted 1 line

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)?

Signature · 4 lines
Ralf Hildebrandt (i.A. des IT-Zentrums)         [email protected]
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 [email protected]
#4 lore raw
In reply to Ralf Hildebrandt
Quoted 57 lines · 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

Quoted 12 lines

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?

Signature · 4 lines
Ralf Hildebrandt (i.A. des IT-Zentrums)         [email protected]
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 [email protected]

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

#5 lore raw
Quoted 74 lines · Justin Piszcz
Quoted 57 lines · 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

Quoted 12 lines

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?

Signature · 4 lines
Ralf Hildebrandt (i.A. des IT-Zentrums)         [email protected]
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 [email protected]
Quoted 1 line

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..

#3 lore raw
In reply to Ralf Hildebrandt

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

Quoted 4 lines
Quoted 1 line

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,

Signature · 2 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
#6 lore raw
In reply to Justin Piszcz

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

Quoted 4 lines
Quoted 1 line

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,

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