21 ms·

Why? SanDisk Extreme is faster except for 4K random writes, according to this table. I don't think 4K random writes matters much for most workloads you are goin

Why? SanDisk Extreme is faster except for 4K random writes, according to this table. I don't think 4K random writes matters much for most workloads you are going to put on a Raspberry PI.

ploxiln 11y ago
You might be surprised about what does some random writes. Imagine you have a bunch of services which don't directly use the disk, but all log to some rotating log files. Or maybe every once in a while, something needs to fsync a random bunch of config files. Yeah that's not so hard, but look again at just how slow random writes can be. An improvement in that (by far worst) statistic is often much more significant than a much larger improvement in linear read or write.
- mortenlarsen 11y ago
  The only situation where I have found disk (SD) IO to be lacking on the RPI is when running apt-get install or upgrade. I have not run any services that generates a lot of log entries or random writes in general. Maybe it is because I don't think of the RPI as a small server but as an embedded development platform.
  - reitzensteinm 11y ago
    But apt-get is exactly where you'd expect a ton of random rights.
    - mortenlarsen 11y ago
      I don't think so. The files are mostly going to be stored contiguously. There is of-cause the journal that is written, but it is not exactly what I would call random. I guess something like SystemTap could be used to determine this but I do not have the time right now.
  - joosters 11y ago
    Try installing the wonderfully named 'eatmydata' package. Running 'eatmydata [command]' will execute the supplied command and will prevent it from syncing buffers to disk. apt-get and dpkg call sync() and fsync() a lot to ensure file consistency in the event of power loss. This forces lots of tiny writes to disk. If you throw away the sync calls, the kernel can do a much better job of coalescing the writes into larger, contiguous I/O operations. Now, obviously you are sacrificing reliability for speed here. You don't want to use 'eatmydata' with a long-running process as you are basically guaranteeing data loss. But for stuff like installing a new package on a system that is not going to suddenly lose power, it will speed things up surprisingly well.

Why? SanDisk Extreme is faster except for 4K random writes, according to this table. I don't think 4K random writes matters much for most workloads you are going to put on a Raspberry PI.

ploxiln 11y ago

You might be surprised about what does some random writes. Imagine you have a bunch of services which don't directly use the disk, but all log to some rotating log files. Or maybe every once in a while, something needs to fsync a random bunch of config files. Yeah that's not so hard, but look again at just how slow random writes can be. An improvement in that (by far worst) statistic is often much more significant than a much larger improvement in linear read or write.

mortenlarsen 11y ago
The only situation where I have found disk (SD) IO to be lacking on the RPI is when running apt-get install or upgrade. I have not run any services that generates a lot of log entries or random writes in general. Maybe it is because I don't think of the RPI as a small server but as an embedded development platform.
- reitzensteinm 11y ago
  But apt-get is exactly where you'd expect a ton of random rights.
  - mortenlarsen 11y ago
    I don't think so. The files are mostly going to be stored contiguously. There is of-cause the journal that is written, but it is not exactly what I would call random. I guess something like SystemTap could be used to determine this but I do not have the time right now.
- joosters 11y ago
  Try installing the wonderfully named 'eatmydata' package. Running 'eatmydata [command]' will execute the supplied command and will prevent it from syncing buffers to disk. apt-get and dpkg call sync() and fsync() a lot to ensure file consistency in the event of power loss. This forces lots of tiny writes to disk. If you throw away the sync calls, the kernel can do a much better job of coalescing the writes into larger, contiguous I/O operations. Now, obviously you are sacrificing reliability for speed here. You don't want to use 'eatmydata' with a long-running process as you are basically guaranteeing data loss. But for stuff like installing a new package on a system that is not going to suddenly lose power, it will speed things up surprisingly well.