[smartmontools-support]BadBlockHowTo suggestion

[Nathan Stratton Treadway <nathanst@on...>]

Thanks for putting together the BadBlockHowTo document; it was very
helpful when I had a disk with bad sectors recently.

A few thoughts:

In both your examples, you suggest that we use dd with "bs=3D4096" to
force the disk to reallocate, although in the second example you also
mention show a "dd" command with "bs=3D512".  It's true that some data
will be lost in either case -- and if you've used the earlier steps to
verify that you have some backup copy of the file in question then you
won't care how much of that file is lost during the reallocation step --
but if you don't have any backup copy of the file and are trying to
recover as much of it as possible, it seems that overwriting only those
disk sectors that are actually failing would be safer and just as
effective.

(In other words, in your first example, only one sector appears to have
failed, so there is no need to overwrite the other three sectors in that
EXT2 block; using "bs=3D512 count=3D1" would let you do what you need
with the minimum collateral damange.)=20


Related to that, it seems a little "cleaner" just to overwrite the
"absolute" sector using "of=3D/dev/hda seek=3D<LBA_of_sector>", rather than
using the partition-specific device file.  Or, put another way, we do
need to figure out which block within which partition we are dealing
with in order to use debugfs to map to the file name -- but there's
probably no reason to keep using this calculated (and therefore more
likely to be incorrect :) ) info when we finally do the "reallocation"
step.... =20

(This is especially true if the LBA_of_first_error is no longer printed
out in hex, as you mention in
  http://article.gmane.org/gmane.linux.utilities.smartmontools/2044=20
, since then you can just cut-and-paste the LBA number onto your command
line....)

(So, I'm suggesting it might make more sense to use something like
  dd if=3D/dev/zero of=3D/dev/hda bs=3D512 count=3D1 seek=3D23421417
as the reallocation command in your first example.)



On a more general note, in both of your examples the "icheck" commands
all found an inode containing the block in question.  In my case one
"icheck" commands that I did returned the message "<block not found>"
instead of an inode number.  I assume this just means that no file is
using the block in question and therefore it's safe to go ahead and do
the reallocation step -- but you might want to mention this possibility
in your document.


Finally, it might not hurt to mention somewhere (e.g. near the top or in
a postscript) that:
  * the sector numbers used by "smartctl -l selftest" and "fdisk -lu"=20
    call the first sector on the disk sector "zero"
  * the first block in an EXT2 filesystem is numbered "zero", and
  * dd's "seek=3DX" and "skip=3DX" argument actually cause dd to start=20
    operations on the (X+1)th block of the given file (i.e. they=20
    cause dd to _skip X blocks_ in the file before starting the copy.

In the end this works out well, since the Nth sector on the disk will be
called "N-1" by smartctl/fdisk and dd will also need to skip past N-1
sectors in order to reach that same sector (and similarly for reaching a
particular ext2 block using "dd bs=3D4096") -- but I think it's useful to
understand why it all works out, especially if the reader tries to do
anything beyond the specific steps given in the document.=20


Hope all this makes sense, and thanks again for pulling together this
document.

						Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst@...  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint =3D 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

[smartmontools-support]BadBlockHowTo suggestion

[Nathan Stratton Treadway <nathanst@on...>]

Thanks for putting together the BadBlockHowTo document; it was very
helpful when I had a disk with bad sectors recently.

A few thoughts:

In both your examples, you suggest that we use dd with "bs=3D4096" to
force the disk to reallocate, although in the second example you also
mention show a "dd" command with "bs=3D512".  It's true that some data
will be lost in either case -- and if you've used the earlier steps to
verify that you have some backup copy of the file in question then you
won't care how much of that file is lost during the reallocation step --
but if you don't have any backup copy of the file and are trying to
recover as much of it as possible, it seems that overwriting only those
disk sectors that are actually failing would be safer and just as
effective.

(In other words, in your first example, only one sector appears to have
failed, so there is no need to overwrite the other three sectors in that
EXT2 block; using "bs=3D512 count=3D1" would let you do what you need
with the minimum collateral damange.)=20


Related to that, it seems a little "cleaner" just to overwrite the
"absolute" sector using "of=3D/dev/hda seek=3D<LBA_of_sector>", rather than
using the partition-specific device file.  Or, put another way, we do
need to figure out which block within which partition we are dealing
with in order to use debugfs to map to the file name -- but there's
probably no reason to keep using this calculated (and therefore more
likely to be incorrect :) ) info when we finally do the "reallocation"
step.... =20

(This is especially true if the LBA_of_first_error is no longer printed
out in hex, as you mention in
  http://article.gmane.org/gmane.linux.utilities.smartmontools/2044=20
, since then you can just cut-and-paste the LBA number onto your command
line....)

(So, I'm suggesting it might make more sense to use something like
  dd if=3D/dev/zero of=3D/dev/hda bs=3D512 count=3D1 seek=3D23421417
as the reallocation command in your first example.)



On a more general note, in both of your examples the "icheck" commands
all found an inode containing the block in question.  In my case one
"icheck" commands that I did returned the message "<block not found>"
instead of an inode number.  I assume this just means that no file is
using the block in question and therefore it's safe to go ahead and do
the reallocation step -- but you might want to mention this possibility
in your document.


Finally, it might not hurt to mention somewhere (e.g. near the top or in
a postscript) that:
  * the sector numbers used by "smartctl -l selftest" and "fdisk -lu"=20
    call the first sector on the disk sector "zero"
  * the first block in an EXT2 filesystem is numbered "zero", and
  * dd's "seek=3DX" and "skip=3DX" argument actually cause dd to start=20
    operations on the (X+1)th block of the given file (i.e. they=20
    cause dd to _skip X blocks_ in the file before starting the copy.

In the end this works out well, since the Nth sector on the disk will be
called "N-1" by smartctl/fdisk and dd will also need to skip past N-1
sectors in order to reach that same sector (and similarly for reaching a
particular ext2 block using "dd bs=3D4096") -- but I think it's useful to
understand why it all works out, especially if the reader tries to do
anything beyond the specific steps given in the document.=20


Hope all this makes sense, and thanks again for pulling together this
document.

						Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst@...  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint =3D 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: [smartmontools-support]BadBlockHowTo suggestion

[Bruce Allen <ballen@gr...>]

> Thanks for putting together the BadBlockHowTo document; it was very
> helpful when I had a disk with bad sectors recently.

Glad to hear it!

> A few thoughts:
> 
> In both your examples, you suggest that we use dd with "bs=4096" to
> force the disk to reallocate, although in the second example you also
> mention show a "dd" command with "bs=512".  It's true that some data
> will be lost in either case -- and if you've used the earlier steps to
> verify that you have some backup copy of the file in question then you
> won't care how much of that file is lost during the reallocation step --
> but if you don't have any backup copy of the file and are trying to
> recover as much of it as possible, it seems that overwriting only those
> disk sectors that are actually failing would be safer and just as
> effective.

I think that the larger blocksize is needed when interacting with the file
system rather than the raw disk.  When dealing with the file system the
kernel buffers the interaction with the disk and can't request less than 8
sectors at once.  This will change in the next release of gnu coreutils,
where new flags (idirect/odirect) will permit interaction with the disk
that bypasses the kernel block buffer.

> (In other words, in your first example, only one sector appears to have
> failed, so there is no need to overwrite the other three sectors in that
> EXT2 block; using "bs=512 count=1" would let you do what you need
> with the minimum collateral damange.) 

As I recall, that didn't work for me because of kernel block buffering.

> Related to that, it seems a little "cleaner" just to overwrite the
> "absolute" sector using "of=/dev/hda seek=<LBA_of_sector>", rather
> than using the partition-specific device file.  Or, put another way,
> we do need to figure out which block within which partition we are
> dealing with in order to use debugfs to map to the file name -- but
> there's probably no reason to keep using this calculated (and
> therefore more likely to be incorrect :) ) info when we finally do the
> "reallocation" step....

This comment makes sense -- I think that I may have had a reason for doing
it the way that I did, but can't remember it...

> (This is especially true if the LBA_of_first_error is no longer printed
> out in hex, as you mention in
>   http://article.gmane.org/gmane.linux.utilities.smartmontools/2044 
> , since then you can just cut-and-paste the LBA number onto your command
> line....)
> 
> (So, I'm suggesting it might make more sense to use something like
>   dd if=/dev/zero of=/dev/hda bs=512 count=1 seek=23421417
> as the reallocation command in your first example.)

OK.  When gnu coreutils releases a new version of dd I'm going to update
the BadBlockHowTo.txt file.

> On a more general note, in both of your examples the "icheck" commands
> all found an inode containing the block in question.  In my case one
> "icheck" commands that I did returned the message "<block not found>"
> instead of an inode number.  I assume this just means that no file is
> using the block in question and therefore it's safe to go ahead and do
> the reallocation step -- but you might want to mention this possibility
> in your document.

Yes, good point.
 
> Finally, it might not hurt to mention somewhere (e.g. near the top or in
> a postscript) that:
>   * the sector numbers used by "smartctl -l selftest" and "fdisk -lu" 
>     call the first sector on the disk sector "zero"
>   * the first block in an EXT2 filesystem is numbered "zero", and
>   * dd's "seek=X" and "skip=X" argument actually cause dd to start 
>     operations on the (X+1)th block of the given file (i.e. they 
>     cause dd to _skip X blocks_ in the file before starting the copy.
> 
> In the end this works out well, since the Nth sector on the disk will be
> called "N-1" by smartctl/fdisk and dd will also need to skip past N-1
> sectors in order to reach that same sector (and similarly for reaching a
> particular ext2 block using "dd bs=4096") -- but I think it's useful to
> understand why it all works out, especially if the reader tries to do
> anything beyond the specific steps given in the document. 

OK!

> Hope all this makes sense, and thanks again for pulling together this
> document.

When coreutils gets updated (real soon now) I would appreciate a volunteer
to help me in updating BadBlockHowTo.txt.  Would you help?

Cheers,
	Bruce