[colug-432] Problem for January Meeting

[R P Herrold]

On Thu, 28 Jan 2016, jep200404 at columbus.rr.com wrote:

> On Tue, 12 Jan 2016 09:12:19 -0500, Scott Merrill <skippy at skippy.net> wrote:
> 
> > As always, feel free to bring with you any ailing or problematic systems
> > for expert diagnosis (or destruction).
> 
> I hope to get some help explaining why dd is having trouble 
> writing to an SDHC module. I hope to have the SDHC module 
> and USB adapter at tonight's meeting.
> 
> There was initial apparent success at amazing speed,
> but reads revealed that it was not actually writing all the zeros.
>  For example: 
> 
>     [root at main flash]# date;time dd if=/dev/zero bs=1M seek=2272 of=/dev/sdb;date
>     Sun Dec 20 14:26:17 EST 2015 
>     dd: error writing ‘/dev/sdb’: No space left on device
>     12922+0 records in
>     12921+0 records out
>     13549174784 bytes (14 GB) copied, 110.059 s, 123 MB/s


that 'dd' error line seems worth pursuing, to find exactly 
where the failure to write lies

I know I have read reports of mis-marked media, not actually 
having the indicated size.  As your example shows, 'dd' has a 
'seek' option, and it would therefore be possible to quickly 
do 'targeted' writes of known patterns at zero, the final, and 
various other locations on a piece of RW media, and then to 
read the results back.  I assume one may automate this 
process, but do not immediately know how to retrieve assumedly 
hard-coded asserted media size information (hard-coded outside 
of a mutable partition table)

It might also make sense to write 'sentinel' patterns at 
powers of two 'distances' into the media, and so be able to 
watch for when a read-back failure starts, and determine true 
size by such a 'binary search'

I'd be tempted to confirm a piece of media was not 
mis-represented early in the diagnosis process

-- Russ herrold