[Sugar-devel] Additional data for corrupted SoaS

[James Cameron]

On Sat, Aug 01, 2009 at 02:40:08PM +0200, Sascha Silbe wrote:
> 
> BTW, the SoaS Caroline gave me on SugarCamp (thanks!) is quite
> unreliable in one of my computers (it also confirms my suspection
> about the trouble she was having with my Assimilator software:
> hardware flakeyness). If you're using this run of sticks at the GPA,
> you can add it to the list of potential causes for stick failure.
> As you're about to buy the next run: Do you have a "sample" model
> that you can try out in lots of different computers? Just run the
> following command in Linux, with only the to-be-tested USB stick
> plugged in:
> 
> dd if=/dev/disk/by-id/usb<press TAB once> of=/dev/null
> 
> e.g. for the stick mentioned above:
> 
> dd if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0
> of=/dev/null
> 
> 
> If there's a problem, an error message will be printed as part of
> the output:
> 
> sascha.silbe at twin:~$ dd
> if=/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0\:0
> of=/dev/null
> dd: reading
> `/dev/disk/by-id/usb-CHIPSBNK_USB_2.0_260917004B813900-0:0':
> Input/output error
> 468448+0 records in
> 468448+0 records out
> 239845376 bytes (240 MB) copied, 14.7675 s, 16.2 MB/s
> sascha.silbe at twin:~$

This means that a particular block could not be read from the device,
either due to a communication problem between your CPU and the device,
or because the device itself has the block marked as flawed.

If the reading of the device fails at the same point each time, then the
latter is more likely than the former.

You may obtain more details on the event from the kernel message log,
using dmesg.

> If it's sucessfull, the whole stick will have been read:

Actually, it is better to say if it is successful then the return status
will be zero.  Judging only by the size of the data or the lack of error
messages is not as reliable.  An easy way to test for zero return status
is to append "&& echo something" to the end of the shell command.  If
the previous command returns zero for success, then the something will
be displayed.

dd has a "noerror" flag that may be useful in testing ... it causes dd
to report the error and try to proceed regardless.  If from using
"noerror" you find that only a small number of blocks are unreadable,
then chances are the damage is localised.

With USB flash devices that report an error in a small area on read,
I've found that if you *write* that area, the error goes away.

Cause of the flaw?  Either a block has deteriorated to the point that it
cannot be read (the lifetime is not infinite), or it was erased as part
of being written but the write did not complete.

-- 
James Cameron
http://quozl.linux.org.au/