[Gllug] JFS and bad blocks

[Peter Grandi]

>>> On Wed, 5 Oct 2005 10:29:36 +0100, Jack Bertram
>>> <jack at jbertram.net> said:

jack> I can't seem to work out how to test a JFS filesystem
jack> for bad blocks and mark them bad.

Thanks for informing us about this. :-)

jack> Anyone using it and can give advice?

Probably someone somewhere. :-).

Some meta points:

  I hate questions phrased like that; for example ostensibly you
  are only interested in knowing whether there is anyone who
  both uses JFS _and_ can give advice, but not in the advice;
  and you are ostensibly not interested in advice, even correct
  advice, from someone who is not _currently using_ JFS, even if
  they used it for twenty years :-) or know it inside out anyhow.

  This ain't pedantic, because in technical settings one should
  be informative and precise as to what one wants to know. Folksy
  talk like this can be very, very misleading.

  Also, questions phrased like that are often silly because they
  are about a detail when for example it is the _purpose_ that
  matters; in this case _why_ are you trying to do that? My
  advice on asking questions, for IRC, but generally applicable:
  http://tinyurl.com/bz8v4

Note let's pretend you asked:

  ''How does JFS handle bad blocks? What can I do about a
    JFS filesystem that's got them?''

The answers, inferring some likely context, are:

  * 'jfs_mkfs' has a '-c' option. This will create a map of
    blocks to avoid allocating, after testing with 'badlocks'.

  * 'jfs_fsck' has no '-c' option because once allocated a
    block cannot be remapped easily; what if the block is in
    the middle of a large extent? Could be done, probably
    not worth doing.

  * When a hard disc has so many bad blocks that they become
    visible to the operating system, that usually means that it
    is either failing, or it should be low-level ''formatted'',
    which means usually running the manufacturer supplied ''bulk
    erase'' utility. This often will either or both rebuild the
    sparing tables and recover by rewriting marginally bad
    sectors.

  * 'fsck.* -c' is most useful for recovery; a (usually slow)
     alternative for recovering stuff on bad media is to use

       dd bs=512 conv=sync,noerror

     which will create an image copy of the partition with all
     bad sectors replaced with zero sectors, and one that can
     often be successfully 'fsck.* -f'.

  * Alternatively, or as well as that, you can try a ''best
    effort'' recovery with GNU tar and its '--ignore-failed-read'
    option.

As to the general issue of Linux file systems and bad block
handling and other often unnoticed features, I have been doing
in the recent past some moderately in depth analysis of file
systems, for example with some detail information here:

  http://WWW.sabi.co.UK/Notes/anno05-3rd.html#050909

BTW, of all file systems I think that 'ext3' is, intentionally:

  http://ext2.SourceForge.net/2005-ols/2005-ext3-paper.pdf

the most recoverable one (rather dispersed and redundant
metadata), but JFS is not too bad, even if any filesystem based
on b[...]-tree obviously has some recoverability issues, as the
'ext3' paper above gleefully points out.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug