Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've got a bunch of compact flash cards that I've used heavily in a professional photo and video capacity.

I'm concerned that one of them is going bad, since I am seeing files (most often video, but occasionally photo) become corrupt on a hard to predict basis. I am absolutely sure this is not related to unmounting the card before removing it - the corruption is visible directly after properly removing the card from the camera.

The problem is, I don't know which card is problematic, and the issue seems to be intermittent, so I can't just shoot them full and look for a bad file (and corruption isn't always apparent even then - if the bad bit(s) are within the data portion of a file, it might not be obvious). The problem is rare enough that I can't reliably reproduce it (except when there's a client with a job with files that absolutely, positively cannot be lost - then it's sure to strike).

I could RMA them all under warranty (they're all Sandisk with lifetime warranty), but I'd prefer not to (how do I justify sending in a batch of 5 cards? what do I use during the month that they're gone?).

I'm looking for a tool that will fix them. Specifically, I need something that will do a write/read/write/read cycle for the whole card, and ideally do a full format to remove any bad bits, as well as letting me know the status (is one card particularly bad? are all the others perfectly fine? what level of errors am I seeing on a general basis?).

I'm aware of the badblocks tool, but was hoping to find something tailored more towards CF (and which would hopefully let me map the bad areas out of use, if it's only a few bits). I would prefer a non-windows tool if possible.

Has anyone else solved this problem without simply blindly replacing your devices? Some of the suspect cards are pretty new.

share|improve this question

2 Answers 2

There are probably better tools but if you want simple and free then you want dd.

Assuming your non-windows is some flavor of Linux or Unix and your cards are empty of any data you want to keep then you can try this:

mount the CF card in your reader, and get its device name. I'm going to assume it's /dev/CF for purposes of this answer. Login as root.

To write the card full with random data

dd if=/dev/random of=/dev/CF bs=1k

You can do this a couple of times (how many is up to you) and if it gets an error before it finishes the whole card then it's a problem with the card.

You can check the read function of the card this way:

dd if=/dev/CF of=/dev/null bs=1k

It should read the entire card with no errors.

When you're finished you will want to reformat the card. First, write the card full of zeros so it can then be formatted in your camera:

dd if=/dev/zero of=/dev/CF bs=1k   

This should write the whole card without error.

My personal opinion is that if you get ANY errors then RMA the card. I wouldn't try to re-use it by re-mapping the bad blocks.

Be aware that even if the card(s) pass the above tests it doesn't mean they're guaranteed good. It MIGHT mean an intermittent error which takes a bit longer than you thought to show itself. On the other hand if it FAILS then you have some data on which to base your RMA decision and some supporting documentation to give Sandisk to justify the RMA.

share|improve this answer
    
Hmmm. I had considered dd, but my understanding is that while the process you outlined will write the card, then read it, it won't verify that what is read from the card equals what was intended to be written to it. I could write the output of /dev/random to another file, then do a comparison... I'm hoping there's an easier method though. –  Paul McMillan Aug 16 '10 at 20:17
    
@Paul McMillan: dd will detect certain problems, not others. And it won't help to compare to /dev/random since its RANDOM it won't be the same the second time. You can create a filesystem on the CF device, write a bit of /dev/random to a disk file (use the dd count parameter) (or any file you want with cp) , then copy the disk file to the CF device and then take an md5 hash (md5sum -b filename) of both the disk file and the CF file. - - - but this is a bit more work than I thought you wanted to invest. –  hotei Aug 16 '10 at 21:02
    
I understand /dev/random. I was referring to running an appropriate amount of it into a file that I could compare to before writing to the card. I think badblocks is the best available tool I've discovered for this job. –  Paul McMillan Aug 16 '10 at 23:46
    
@paul~: I thought you might, but had to make sure since others will also come across these posts. –  hotei Aug 17 '10 at 2:13

If you have access to a Windows machine you could try Check Flash. This link is just to a review of it with a nice screenshot (the actual website is in Russian)

I've not personally used it, but assuming the screenshots/reviews are legitimate it seems like a sensible way of testing flash drives.

share|improve this answer
    
P.S. Here is the link to the actual developer's website (in Russian): mikelab.kiev.ua/index.php?page=PROGRAMS/chkflsh –  drfrogsplat Aug 16 '10 at 3:28
    
Thanks, I'll have to look into that. Seems an interesting option, and it might do the trick. Certainly looks user friendly. –  Paul McMillan Aug 17 '10 at 1:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.