Tuesday, March 26, 2013

Using Synchrotech's X4SD USB 2.0 SD Card Reader Four (4) Slot for SD Card duplication

X4SD USB 2.0 SD Card Reader Four SlotSynchrotech's X4SD USB 2.0 SD Card Reader allows simultaneous access to four SD Card style media. In Automating X4SD USB 2.0 SD Card Reader Four (4) Slot Operations Synchrotech outlines several techniques for automating the copying of files to the device's multiple slots. Here we explore making exact binary copies of media using the device. A common use of this process is duplication.

There's various ways to do do device duplication or byte-for-byte copies of media. Whether we're duplicating CD-ROMs, hard drive disks, SRAM PC Cards, or other removable media, the Unix dd is frequently preferred for these types of operations. While we can execute card to card duplications from one X4SD slot to another, the most common use for the reader is to write an existing SD Card image to all four slots simultaneously. To that end we'll create a binary image of a master SD Card and then use that master to write to blank cards.

Creating an image of the SD Card

dd works with block devices, so we need to unmount the SD Card. To make this simple, we'll be using just one of the X4SD slots at this stage. We'll be using Mac OS X for our example and detail the difference for OpenBSD and Xubuntu. First, we need to identify the mount point of the inserted card. Calling mount in the terminal shows us the information we need (we're leaving out the rest of the output here).

/dev/disk1s1 on /Volumes/NO NAME (local, nodev, nosuid)

We use that information to unmount the mounted device.

[kyoto:~/Desktop] rds% sudo diskutil unmount /Volumes/NO\ NAME
Volume /Volumes/NO NAME unmounted

OpenBSD and Xubuntu would use umount /[devicepath]. Using the block device reference to the X4SD slot, we can copy the card to a binary file using dd.

[kyoto:~/Desktop] rds% sudo dd if=/dev/disk1s1 of=sdcard.bin
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)

Writing the image to SD Cards

Inserting a new card into the X4SD, then unmounting it, we can create a duplicate of the original. We then test it using cmp to see if it is identical to the binary file.

[kyoto:~/Desktop] rds% sudo dd if=sdcard.bin of=/dev/disk1s1
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)
[kyoto:~/Desktop] rds% cmp /dev/disk1s1 ~/Desktop/sdcard.bin
[kyoto:~/Desktop] rds% 

Here we write to all four slots simultaneously on a Xubuntu machine. It's feasible that using hubs and multiple X4SD, we could write to more than four cards at once on a machine with enough CPUs/CPU cores. However, there's a practical limit to the amount of I/O operations one would want to run at the same time. Perhaps writing to each bank of cards sequentially would be the best practice? Since I was only provided a single test unit, that remains an academic question.

rds@okinawa-lin2:~$ sudo dd if=sdcard.bin of=/dev/sdc1 & \
&& dd if=sdcard.bin of=/dev/sdd1 & \
&& dd if=sdcard.bin of=/dev/sde1 & \
&& dd if=sdcard.bin of=/dev/sdf1 &

1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 270.799 s, 3.7 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 423.987 s, 2.4 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 775.1 s, 1.3 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 860.479 s, 1.2 MB/s

Appendices

Determining Media Paths

Here's the abridged results of running mount on our various test systems with the X4SD plugged in and all four of its slot occupied. This output will look different based on what's connected to an individual system.

OpenBSD
sd0i on /mnt/s1 type msdos (local)
sd1i on /mnt/s2 type msdos (local)
sd2i on /mnt/s3 type msdos (local)
sd3i on /mnt/s4 type msdos (local)

Xubuntu Linux
/dev/sdd1 on /media/BF2C-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdf1 on /media/02A3-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sde1 on /media/3A3A-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdc1 on /media/5AED-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)

Mac OS X
/dev/disk2s1 on /Volumes/NO NAME 3 (local, nodev, nosuid)
/dev/disk4s1 on /Volumes/NO NAME 2 (local, nodev, nosuid)
/dev/disk3s1 on /Volumes/NO NAME (local, nodev, nosuid)
/dev/disk1s1 on /Volumes/NO NAME 1 (local, nodev, nosuid)

My Test Systems

Here's the results of running uname -a on our various test systems.

OpenBSD okinawa-bsd2.my.domain 5.1 GENERIC.MP#207 amd64
Linux okinawa-lin2 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
Darwin kyoto 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

Code example disclaimer

Technology Musings grants you a nonexclusive copyright license to use all programming code examples from which you can generate similar function tailored to your own specific needs.

All sample code is provided by Technology Musings for illustrative purposes only. These examples have not been thoroughly tested under all conditions. Technology Musings, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

All programs contained herein are provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.