Re: Testing memory cards
- From: Jim Howes <jimhowes@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Jan 2008 16:28:23 +0000
John Blundell wrote:
Any suggestions for software for testing memory cards generally, and specifically for checking the true capacity? Today I have been trying out a 2 GB SD card, but it fell over when about half full.
Any particular reason you don't think that the number of sectors reported to the USB Mass Storage system would disagree with the number actually there?
On the test I have just run I was copying a large folder full of sub-folders and files. It failed with a message "Unable to create the folder 'name'. The system cannot find the path specified".
FAT filesystems have a limit on the size of the root directory, so if you are trying to create more files than the root directory has room for (the exact number I forget, 512?) then you will get errors like this.
Subdirectories have no such limitations, I think. Long file names in FAT use multiple directory entries because of the bizarre way in which the long file names are stored (every 13 characters of a file name requires a directory entry, plus a final entry which contains the 8.3 equivalent and 'real' directory date (time,date,starting cluster)
Calling up properties for the drive, I got -
Used space 1,048,801,280 bytes
Free space 1,004,965,888 bytes
Capacity 2,053,767,168.
As this is the second test I did on the card, and the first test failed near the end of writing a Zip file of a bit over 1 GB, I am suspicious about the true capacity.
Because of the way ZIP archives are constructed, depending on what you use to make the ZIP file, you will run into grief when the size of the file exceeds half the free space because some ZIP creation stuff copies the compressed stuff (you may see a temporary file during the creation process) and bolts on headers and TOC afterwards.
Personally, my answer to testing flash is
A) Don't, because the continuous writing involved in any test process is likely to do you no good whatsoever due to wear
B) Avoid any restrictions imposed by the filesystem being used on the flash device. This usually means writing to sequential blocks, which is hard to do from windows (very easy in a unix environment, you just treat the block devices as a char device and lob data at it until it's full). This causes other problems as some devices have 'holes' (some CF cards have a block 0, and no actual memory located where the rest of cylinder 0 should be, which is annoying)
C) Avoid restrictions imposed by the the firware. Does the device feature stuff like hidden (secure) sections that you cannot access until you communicate in some undisclosed manner (using some binary-only device driver and utility)? The firmware can also hide errors by correcting them transparrently (in much the same way that bad block replacement on hard disks happens)
In short, don't test it, but also don't rely on it (make backups, etc.)
.
- Follow-Ups:
- Re: Testing memory cards
- From: John Blundell
- Re: Testing memory cards
- References:
- Testing memory cards
- From: John Blundell
- Testing memory cards
- Prev by Date: Re: Is this possible?
- Next by Date: Re: Is this possible?
- Previous by thread: Re: Testing memory cards
- Next by thread: Re: Testing memory cards
- Index(es):
Relevant Pages
|