18

I've been installing some linux distributions onto an SD card from my MacBook, although they take over an hour to transfer a few hundred MB (using dd and /dev/disk1).

dd output

If you look at the above output it's working at roughly 0.31 MB/s! The SD card is a Class 10, and my MacBook Pro is the 2.66 GHz Intel Core 2 Duo, 4 GB 1067 MHz DDR3, and OS X Lion 10.7.4. Here is the hardware report for the card reader:

Built in SD Card Reader:

Vendor ID: 0x05ac
Product ID: 0x8403
Revision: 1.00 Serial Number: 9833

SDHC Card:

Capacity: 7.97 GB (7,969,177,600 bytes)
Removable Media: Yes BSD Name: disk1
Partition Map Type: MBR (Master Boot Record)
S.M.A.R.T. status: Not Supported
Volumes:

PI:
Capacity: 7.96 GB (7,964,983,296 bytes)
File System: MS-DOS
BSD Name: disk1s1
Content: DOS_FAT_32

Any ideas why the transfer to /dev/disk1 is so slow and how I could speed it up?

Improve this question
3
  • Sounds like a hardware problem to me. I've heard 2011 MBPs have a bad SD reader, but could be a problem with earlier ones as well. Try another SD card, but it could well be a problem with the card reader, which is unfortunately attached to the logic board in most MBPs. – robmathers Jul 11 '12 at 20:20
  • I bought the laptop in 2009, Fedora has been copying now for 2 hours and I've given up. New card reader time I think. – StuR Jul 12 '12 at 9:30
  • Interestingly the sequential data-rate is much higher if you use Finder or Disk-Utility as the culprit seems to be the buffering of /dev/disk* as explained in the answer of @pci – iolsmit Mar 22 '13 at 12:40
40

Just ran into the same problem and it seems to be that /dev/disk* is slow because it is buffered. If you use the corresponding rdisk device (ex: /dev/rdisk1s1) you should get the speed you expect. This is apparently a BSD thing.

Example:

% sudo dd if=pi.bin of=/dev/disk1 bs=1m count=4095
^C408+0 records in
407+0 records out
426770432 bytes transferred in 1393.452305 secs (306268 bytes/sec)

% sudo dd if=pi.bin of=/dev/rdisk1 bs=1m count=4095
4095+0 records in
4095+0 records out
4293918720 bytes transferred in 378.669512 secs (11339489 bytes/sec)

Ref:

Improve this answer
7
  • 1
    This is the best answer I have found to this question as I was able to confirm the results. Went from ~1.35 MB/sec to 20MB/sec :) – nessence Mar 10 '13 at 3:55
  • 1
    That's of course a shame (for Apple/BSD) - although, using dd is giving you the best possible performance as you have one long write (or read) access; on file level and with random access your performance will vary a lot, depending on the SD-card - And: excellent finding @pci ! – iolsmit Mar 22 '13 at 12:42
  • 3
    Its a long story, but you just saved me $90 worth of salmon that was going to go bad if i couldn't fix my smoker in time. – deweydb Jul 13 '14 at 23:45
  • 3
    Kind of ridiculous how you can download a file at 20+Mbps over thousands kilometres, and the last few meters it's wireless. But transferring data a few centimetres over a hard connection is much much slower. – Jonathan. Jul 30 '14 at 15:14
  • Thanks. I was looking at copying 7GB of data over ~ 10 hours when I decided it's not acceptable and found this answer - very helpful. – Barak Sep 11 '15 at 9:51
3

It could well be that the SD-card is that slow.

Take a look at this benchmark (Random Write, 4 KB (QD=1) [MB/s]) and you will see that most SD-cards have a lousy write performance (below 100 kB/s) for small files - and a typical linux installation consists of a lot of small files been written to disk.

The internal card-reader should be capable of reading/writing at least 20 MB/s - it's very unlikely that another card-reader will improve your experience with this very SD-card.

Once all the files are written, i.e. the system is installed, you may actually be able to run Linux from the SD-card in an acceptable speed - as it's mostly read access.

Improve this answer
3
  • 1
    For the down-voter, see this post – iolsmit Jul 20 '12 at 0:23
  • It would be a good experiment though to test the card in another reader known to be good, and test a card known to be good in the suspected reader. Also notice that all the "paperwork" for creating new files (as opposed to writing their content) in the file system data structures is very large for many small files. – Thorbjørn Ravn Andersen Mar 5 '13 at 12:49
  • Whle SD cards are not very fast, the speed (328198 bytes/sec and later 288881 bytes/sec) cannot is unimaginable for today's SD cards (feels more like floppy drives). Since this is 'dd', it means a single file - not multiple small files. – Barak Sep 11 '15 at 9:50
1

If the card is mounted with the sync option, this means every file close causes the write to be flushed to disk and thus your performance on small files will be terrible when compared with large files. If you remove the sync from the mount options, then there is no guarantee that writing a file causes it to go out to disk -- you have to manually call sync from the command line, or unmount the device before removing it or powering down. However, without sync you should see small files write performance improve drastically.

Improve this answer
1
  • 1
    According to man mount, async is the default already. – nohillside♦ Sep 17 '12 at 5:15
1

No, this is clearly some issue with the Mac OS. I get significantly faster performance when I do this same operation using Linux on a virtual machine running on the same Macintosh. I.e., the VM is about 5x faster than the native OS.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .