Re: Results of CheckDS.py

On Friday 16 February 2007 13:10, Ed Leafe wrote:
> On Feb 14, 2007, at 1:50 PM, Toby Dickenson wrote:

> > This could be a DirectoryStorage bug, but is more likely to be bad
> > RAM, bad
> > disk or disk controller, etc. The other output of checkds will log
> > the names
> > of these 19 files; it may be interesting to inspect them.
> > (and I would be interested to receive copies by private email)
>
> 	Attached. I saved the output and extracted every line with 'bad md5'
> in it:
>
> object data files with bad md5 checksum: 
> A/o0/00/00/00/00/00/19/782/0368EA8DDC2B6B77 
> object data files with bad md5 checksum: 
> A/o0/00/00/00/00/00/2B/D7C/036715969B58EFCC

Sometimes the corrupt files can give you a clue about the nature of the 
damage, and point to a possible cause. Sadly this isnt the case for these 
files.

All the redundant information in the file headers is correct; the files have 
the right length and right filename. The bodies of the files are filled with 
plausible data; all of them can still be unpickled without error. The only 
hint of a problem is the incorrect md5.

The files dont seem to have anything in common; they were written at different 
times, to different objects, and therefore should be in different physical 
locations on disk.

If you can find non-corrupt versions of any of these files on a backup then it 
would be interesting to look at the differences.

>  I also noticed odd dates on these files:
> -rw-r----- 1 ed users 111K 1970-01-22 21:09 A/
> o0/00/00/00/00/00/09/253/034F8DBC48FF07B3
> -rw-r----- 1 ed users 725K 1970-01-22 21:09 A/o0/00/00/00/00/00/09/
> D4A/034FA4556935B1DD
> -rw-r----- 1 ed users 177K 1970-01-22 21:10 A/o0/00/00/00/00/00/0A/
> 31B/034FA80F7B2F3380
...
> 	These aren't the only files with anomalous dates; there are
> thousands of such files with dates in the 1970s.

That is strangely selective inode damage. mtime is wrong, but many other inode 
fields are intact. A possible simple explanation is the system clock has been 
set to 1970 recently. That would cause these curious timestamps, but should 
not be related to the more serious corruption problems.

If you are sure that the clock has always been set right then I guess this 
again points to a hardware or OS problem.

Im sorry I cant be more help

-- 
Toby Dickenson

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV