On Sun, 29 May 2011, Michael Stumpf wrote:
I'm looking for a filesystem-level tool to perform something similar
to what badblocks does at the drive level. I can certainly write it
on my own (I'd build it as a Perl or Python script), but if someone's
already invented this..
(The intended purpose is to validate that there are no quirks/bugs in
the overall fs.)
If you can take the partition offline, then fsck -fC might work, although
it'll depend on the fileysstem type... And fsck doesn't actually read the
file blocks (that I'm aware of)
For something crude, you can use find to descend a heirarchy then copy the
file, or maybe even something like
cd /top-level/dir/
fgrep -r "wumpus" .
that'll perform a read of every file - well, mostly as some might be in
the filesystem cache.
But if you want to make sure every file block belongs to a file, and the
structure (directory) integrity is there, then fsck is probably the best
bet...
Another way might be to recursively compute md5 checksums for all files -
then do it again and compare.. (at a later date?)
You might want to look at something like tripwire to automate this though.
(Obviously won't work if you get the same error at the same place every
time though!)
One of the burn-in tools I have is a script that writes a file of random
numbers - md5's it. Then copies this file to n+1, then copies n+1 to n+2,
then n+2 to n+3 and so on, then md5's the final file. The file-sizes are
typically double RAM size to negate the effects of cache (same idea as
bonnie)... However if there's a failure, then it's it's not clear where
the issue is - memory, PCI bus, SATA cable, disk platter?
Of-course in a RAID array, looking at it from the fileysstem level (or
even the block level) isn't going to read all platters of all disks - you
need to use the /sys/block/mdX/md/sync_action mechanism.
Gordon
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
