Hello Seth, hello list,
once more for the records.
I have updated my gcc from 2.95-2 to 2.95-3 and recompiled the whole 2.4.19
vanilla kernel I patched before using the 2.4.19/xfs-2.4.19-all-i386.bz2
patch (no other kernelpatches).
After booting with this kernel and mounting/unmounting my corrupted XFS
partitions I simply did a "xfs_repair /device" (device here is a placeholder ;-)
which produced some messages I attach to this mail. The xfs_repair (which I
have updated to the recent xfsprogs-2.0.3-0.i386.rpm) went through without
interaction, hangs or whatever. After manually mounting the partitions I could
see that a lost+found was created, but it was empty, in both cases. Now I can
(auto)mount my partitions as before, no data seems to be lost, it works like
a charm. Hopefully such a corruption will not repeat.
A point from my wishlist, please integrate XFS into the main kernel releases
(as is done with JFS in the moment)
Thank you for helping me, and keep up the good work.
cheers, Gerd
PS: the output of xfs_repair, both partitions
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
root inode marked free, correcting
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
imap claims a free inode 134 is in use, correcting imap and clearing inode
- 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) ...
- 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 / ...
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
ir_freecount/free mismatch, inode chunk 0/128, freecount 44 nfree 43
- found root inode chunk
root inode marked free, correcting
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
imap claims a free inode 143 is in use, correcting imap and clearing inode
imap claims a free inode 147 is in use, correcting imap and clearing inode
- 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
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- 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
- agno = 16
- agno = 17
- agno = 18
- agno = 19
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 / ...
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
> At 09:43 26-8-2002 +0200, johncoltrane39@xxxxxx wrote:
> >I also decided to update to the recent xfsprogs 2.0.3 from the ftp server
> >this evening and to give xfs_repair a try. I cannot imagine what has
> happened
> >to the xfs partitions, in my view it seems related to the update to the
> >2.4.19, but going back to the painless 2.4.16 didn't help. In the moment
> I
> >read in
> >the FAQ that gcc 2.95-2 should not be used, may be I should update to
> 2.95-3,
> >what's recommended in the FAQ
>
> Drop 2.95.2 and get 2.95.3 or later. 2.95.2 is known to miscompile some
> code (in the past). Since 2.95.3 is publicly available and a bugfix
> release
> that one should be used instead.
>
> >Any further suggestions ?
>
> Capture the output from an xfs_repair if you can.
>
> Cheers
>
> --
> Seth
> It might just be your lucky day, if you only knew.
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
|