How to tell if CF card is faulty?

[Rob Bradford]

My answer may not be of use, buy a cheap 32Mb card, there are still some about and they cost next to nothing. If that shows the same problem then suspect your camera, if not you have a low capacity card to use until you replace your faulty card.

Rob.B

[Tim S]

'Scuse quoting - didn't get the original post...

Linux - excellent. Try running "badblocks" over the card, eg:

badblocks -p 10 -w /dev/sd?

Where /dev/sd? is the device node for the CF card (whole disk, not partitions). If you have any SATA drives present, please watch out as later versions of linux present them as pseudo SCSI devices too, so /dev/sda *might* be your main disk and not the CF card.

The above will give it ten passes (change the -p option for more or less) of writing 4 data patterns over the CF and verifying them.

If no errors, try -p and run it overnight.

Note that this is a destructive test(!) so save your data off it first.

I know this works, had a dodgey Crucial CF card once, and badblocks showed up errors in roughly the places I expected them based on how many pictures were taken before the camera choked.

You'll need to reformat the card afterwards too.

HTH

Tim

[Mathew J. Newton]

Catch up! ;-)

Mathew

[Tony Hwang]

Hi, Or format/write/read from a PC throught a reader. Tony

[John Stumbles]

Well funnily enough I have another CF card that's playing up which I need to test so I tried badblocks. I tried it without the -p 10 since apart from taking a lifetime to run, flash memory can only do a limited number of write cycles. badblocks didn't show any problems so I tried to re-test by hand (as it were). I did:

# dd if=/dev/urandom of=test.file bs=1M count=256

256+0 records in 256+0 records out

Avebury:/home/john/pix/cftest # ll total 262412 drwxr-xr-x 2 root root 4096 2005-04-06 11:59 . drwxr-xr-x 87 john users 4096 2005-04-06 11:58 ..

-rw-r--r-- 1 root root 268435456 2005-04-06 12:01 test.file (file is 256M i.e. 256 * 1024 * 1024 - same as 256M CF card isn't it?)

# dd if=test.file of=/dev/sda1 bs=1M dd: writing `/dev/sda1': No space left on device

249+0 records in 248+0 records out

(Hmmn, 260,046,848 bytes: card seems a bit short, but I don't think I can be mistaken about a "256M" card being 256*1024*1024 - it's still more than 256,000,000. I'm assuming it successfully wrote 248 records and failed on the 249th)

# dd if=/dev/sda1 of=test.out bs=1M

248+1 records in 248+1 records out

(Why am I getting 248+0 when writing, 248+1 when reading back? What does the + figure mean? man dd and info coreutils dd invocation doesn't tell me.)

# dd if=test.file of=test.248 bs=1M count=248

248+0 records in 248+0 records out

# ll test.out test.248

-rw-r--r-- 1 root root 260046848 2005-04-06 12:27 test.248

-rw-r--r-- 1 root root 260292608 2005-04-06 12:26 test.out

(Something wrong here: why am I getting different file sizes? Maybe it's related to dd reporting 248+1 records for some operations and 248+0 for others.)

I then tried truncating both files to 247M and comparing, and found no difference, so looks as if the fault isn't showing up with this test either - seems to be intermittent.

Can anyone help me with the + number issue with dd though?

[Mike Mol]

Assuming you're running a sufficiently recent kernel (2.6.x, for stable), look at /sys/block/sda/sda1/size to get the size of the device, as the kernel sees it. Hard disk drive manufacturers measure disk sizes in si units instead of traditional computing units. (1KB to them is 1000 bytes, not 1024 bytes.) This means my "10.2GB" seagate drive actually only holds 9.6GB of data. (Flamewars of GiB vs GB aside, of course) It's possible that the manufacturer took advantage of the same marketing-freindly measuring system.

I'm not sure, but dd might not be counting partial records after an aborted write. (i.e. when the end of the disk is reached.) If that's the case, you're seeing a bug in your version of dd.

The y in "x+y records in/out" refers to a partial record. Since you're using a huge blocksize (1M), and the device's size apparently isn't a round number of MB, dd can't write a complete 249th record, typically either because there isn't enough space, or there isn't enough data with which to write.

This behavior is normal. If dd reads or writes a partial record, it

*should* report "+1" instead of "+0".

You're on the right track. Judging from the differences in file sizes, the +1 referred to an additional 240K beyond the 248MB you specified by combining the bs argument with the count argument.

test.out is an image of all the data on your flash disk. test.248 is only the first 248MB, and lacks the final 240K.

You'll find that test.248 is identical to the first 248MB of test.out, because test.248 represents a subset of all the space on your disk, while test.out represents the entire disk.

HTH

Mike

[Joe Beanfish]

On 6 Apr 2005 06:54:42 -0700, John Stumbles wrote: ...

...

The +1 means 1 partial record (less than bs) was read/written. So something between 248M and 249M was read/written.