filesystem-level tool to validate array

filesystem-level tool to validate array

[Michael Stumpf]

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.)

Re: filesystem-level tool to validate array

[Nikolay Kichukov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
perhaps a complete fs check via fsck ?

Cheers,
- -Nik



On 05/29/2011 11:17 PM, 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.)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN40OwAAoJEDFLYVOGGjgXEfMH/3EuiJMEIH25WAFbfdv4lgl/
vDvFvb7BpPugnws4qffyJ3cWZu/g39OjrvvAf00xFZXy+OYv0mTtdnNiDBZh/3Tp
lT+p4b1zNsb9yujEFM0OhjaDjq89FytRNHIIPXl9OtvAWi/z+JdGY9ucyFqjl04L
EUaur3ofW0ys1rCLFHvk7Lg3F74E0wk/5v7Ivlop4ECYbgbzM56sLIZ1b980GWCF
kLlz1OdakoZw3Zl9LOdGVqOtmd2PJrhUzYjILSgUIPTVjAFLbKt9oEE1Y5uBJOhm
e5bY9K7YuYVnQ52Vmbz7Y4nxdIAGHp7NDne2jQoGhObKlbzoth4k/IOE6SoR3R4=
=r5BC
-----END PGP SIGNATURE-----

Re: filesystem-level tool to validate array

[Bernd Schubert]

On 05/29/2011 10:17 PM, 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.)

Well, that is hard task and I don't know of a single tool. Here is what
is similar to badblocks:
http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/ql-fstest/

And here is a posix test suite:
http://www.tuxera.com/community/posix-test-suite/



Cheers,
Bernd

Re: filesystem-level tool to validate array

[Gordon Henderson]

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