Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

3 Answers

up vote 10 down vote accepted

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:

share|improve this answer
    
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
    
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
add comment

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.

share|improve this answer
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
add comment

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.

share|improve this answer
1  
According to man mount, async is the default already. –  patrix Sep 17 '12 at 5:15
add comment

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.