Problem with xfs_repair
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]
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 withxfs_repair
xfs_repairgave 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.
* 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_repairpatch 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]
Am Freitag 28 Juli 2006 10:29 schrieb Ralf Hildebrandt:
Quoted 4 lines
Quoted 1 line
2. Try the
xfs_repairpatch 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
Quoted 57 lines · Ralf Hildebrandt
xfs_repairgave 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
Quoted 74 lines · Justin Piszcz
Quoted 57 lines · Ralf Hildebrandt
xfs_repairgave 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 128Quoted 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..
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