My wife told me today, that she has an issue with her camera, a Nikon D3100, and the memory card, a 16GB SDHC Class 6 card from Platinum.
Well as you can imagine, as a Linux Admin, I'm not the guy who fixes cars and laundry machines or know how to perfectly paint a wall. So as this problem goes more into my league, I can at least prove myself in knowing stuff about technology. Of course I received a raising eyebrow but she let me do my checks anyway.
The Nikon D3100 became very slow, already at the start. The SDHC is a class 6 card, as mentioned before, so that's not the slowest card available. After taking a few pictures, the camera froze and it took forever to save a few pictures on the card. Also the powering off of the camera took a long time. A switch of the memory card (we put in a much older SD card) confirmed that something must be wrong with the SDHC card - the camera was now much faster and working well again.
I plugged the SDHC card into my Debian Wheezy machine (through a USB-multi-slot-bridge). fdisk showed that the SDHC's file system is formatted in FAT32:
fdisk -l /dev/sdf
Disk /dev/sdf: 15.7 GB, 15727591424 bytes
255 heads, 63 sectors/track, 1912 cylinders, total 30717952 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdf1 8192 30717951 15354880 c W95 FAT32 (LBA)
Let's check this bad guy with fsck:
fsck /dev/sdf1
fsck from util-linux 2.20.1
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
72:49/4f, 73:4b/20, 74:4f/4e, 75:4e/41, 76:20/4d, 77:44/45, 78:33/20
, 79:31/20, 80:30/20, 81:30/20
1) Copy original to backup
2) Copy backup to original
3) No action
? 1
Leaving file system unchanged.
/dev/sdf1: 902 files, 101166/479712 clusters
Hmm.. Indeed. Something doesn't look right. As you can see, I tried to fix the issue with the option 1 (copy original to backup), but that didn't work.
I decided to delete the partition and recreate it manually:
fdisk /dev/sdf1
Command (m for help): d
Selected partition 1
Command (m for help): w
The partition table has been altered!
fdisk /dev/sdf1
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-30717951, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-30717951, default 30717951):
Using default value 30717951
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Then format the new partition with FAT32:
mkfs.vfat /dev/sdf1
mkfs.vfat 3.0.13 (30 Jun 2012)
Another file system check told me that everything was OK. However once back in the Nikon camera, the same freezes still appeared.
Maybe the card is really dying - but how can this be verified? For hard drives there is the SMART table to find some hints, but how on SDHC cards?
By chance I came across F3 (http://oss.digirati.com.br/f3/) which is a program the find determine a fake SD cards by writing and reading the card until all space is used. I figured I could use the same tool to detect bad sectors as well. So let's give F3 a shot.
Download and compile is pretty easy on Linux:
wget https://github.com/AltraMayor/f3/archive/v2.2.zip
unzip v2.2.zip
cd f3-2.2/
make linux
This creates two binary files: f3read and f3write. To be able to use these commands, the card's file system must first be mounted:
mount /dev/sdf1 /mnt
First we launch f3write to write to the SDHC card.
Remember that the card is now completely empty! Do not do that when you still have pictures on the card!
./f3write /mnt/
Free space: 14.62 GB
Creating file 1.fff ... OK!
Creating file 2.fff ... OK!
Creating file 3.fff ... OK!
Creating file 4.fff ... OK!
Creating file 5.fff ... OK!
Creating file 6.fff ... OK!
Creating file 7.fff ... OK!
Creating file 8.fff ... OK!
Creating file 9.fff ... OK!
Creating file 10.fff ... OK!
Creating file 11.fff ... OK!
Creating file 12.fff ... OK!
Creating file 13.fff ... OK!
Creating file 14.fff ... OK!
Creating file 15.fff ... OK!
Free space: 0.00 Byte
Average writing speed: 10.77 MB/s
Once the card was fully written (it may take a while, be patient), we can read the written files from the card:
./f3read /mnt/
SECTORS ok/corrupted/changed/overwritten
Validating file 1.fff ... 2097152/ 0/ 0/ 0
Validating file 2.fff ... 2097152/ 0/ 0/ 0
Validating file 3.fff ... 2097152/ 0/ 0/ 0
Validating file 4.fff ... 2097152/ 0/ 0/ 0
Validating file 5.fff ... 2097152/ 0/ 0/ 0
Validating file 6.fff ... 2097152/ 0/ 0/ 0
Validating file 7.fff ... 2097152/ 0/ 0/ 0
Validating file 8.fff ... 2097152/ 0/ 0/ 0
Validating file 9.fff ... 2097152/ 0/ 0/ 0
Validating file 10.fff ... 2097152/ 0/ 0/ 0
Validating file 11.fff ... 2097152/ 0/ 0/ 0
Validating file 12.fff ... 2097152/ 0/ 0/ 0
Validating file 13.fff ... 2097152/ 0/ 0/ 0
Validating file 14.fff ... 2097148/ 4/ 0/ 0
Validating file 15.fff ... 1303728/ 0/ 0/ 0
Data OK: 14.62 GB (30663852 sectors)
Data LOST: 2.00 KB (4 sectors)
Corrupted: 2.00 KB (4 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 16.59 MB/s
There was a data loss of 2KB (4 sectors), interesting. So something is definitely wrong with this SDHC card.
No comments yet.
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office OpenSearch PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder