http://oss.sgi.com/bugzilla/show_bug.cgi?id=803
------- Additional Comments From chris@xxxxxxxxxxxxxxxxx 2008-12-04 17:04 CST
-------
I have to add the following detail which might be of interest:
The very first time I ever checked the XFS filesystem was with the version of
xfs_repair that came with xfsprogs-2.5.6-20 of SuSE 9.x. That xfs_repair found
also quite a lot wrong nblocks which (it said it) repaired, but it also found a
"corrupted dinode" which it could not repair.
This was for me the motivation to download and compile from source the latest
(2.10.1) version of xfrprogs and try that one.
Indeed, the "corrupted dinode" was corrected by xfs_repair 2.10.1. However, all
other errors (the wrong nblocks, I guess the same ones for both versions) were
found but were not corrected.
Could it be that all the "wrong nblock" errors were introduced by a bug in
xfs_repair 2.5.6?
I am adding this detail because my backups (done with rsync on ext3 filesystems)
seem to have intact every file that I check, for which I get now the 990 error
as reported above.
This mans that the files were OK at the time they were rsynced and got corrupted
later. Since I rsync every day and since rsync never complained about an IO
error, I guess that the XFS filesystem was intact - up to the point that I
decided to "repair" it with xfs_repair 2.5.6!
Now, after I upgraded xfsprogs and after I got all these uncorrectable errors -
only now do I get IO errors when I rsync!
Did the old (or even the new) xfs_repair corrupt my XFS filesystem in the first
place?
Just a possibility to explore - for the moment I cannot find any other
explanation for the combination of all the above facts.
Chris Karakas
http://www.karakas-online.de
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|