I'm using ARM boxes running Linux 2.6 (I'm stuck with this kernel version unfortunately). The boxes boot off of an SD card, and use a secondary SD card for storage. The boxes have approximately 256MB of memory.
Both SD cards are encrypted with dm-crypt, but I don't believe that this has a major impact on the read/write performance, because the performance was pretty abysmal before I implemented disk encryption. I don't have exact numbers to back up this claim, but just as an example, writing 1GB to an SD card would take upwards of an hour, without dm-crypt in use.
Under normal usage, the read/write speeds are good enough. However, certain tasks such as building software from source tend to lock up on I/O operations, locking up for minutes at a time. Specifically, I believe that the write operations are the ones that block for a long time. I finally found out about the tool iostat, which provided some useful information.
While a program (example: configure script) is blocking, I can run
watch iostat. Watching the Blk_wrtn field seems to confirm that the bottleneck causing lock-ups is the write operations. Specifically, during a blocking write operation, the dm-1 device (second SD card's unlocked partition) has N blocks written to it, while the mmcblk1 (second SD card) has M blocks written to it, where M < N. M increases as time passes, until it is eventually equal to N, at which point the write operation is complete and the program continues executing. As of writing this, the Blks_wrtn/s is approximately 10 for mmcblk1 and dm-1.
I conclude from this observation that blocks are written to the dm-1 pseudo-device immediately, and are then flushed to the physical disk; something about this flushing operation is taking longer than it should.
These are the options I have tried / considered to try to improve the SD card write performance:
- Upgrade to a newer kernel with better drivers / performance: I would love to have a newer kernel, but we are stuck with what the manufacturer provides. I am still trying to figure out if it would be possible to use a newer kernel.
- Use a different IO scheduler for the SD card: I tried switching between deadline, CFQ, and noop, with no noticeable difference in performance.
- Use higher-class SD cards: I'm actually not sure what class the SD cards provided by the manufacturer are, but I have tried switching to class 4 SD cards, with the same performance. I don't think the SD card itself is the bottleneck; it's possible that the readers themselves are the bottleneck, but I don't know how to check this.
- Use a different filesystem on the SD cards: I'm currently using Ext4. Would a different filesystem make a major difference here?
Is there anything I can do to improve the speed when writing to SD cards?