3 ms·

Don't forget the Pi (generally) uses flash. So seek speeds are irrelevant. If you're writing the following in 1ms: Apr 4 22:50:59 heating kernel: [14572.

• tjoff 11y ago
  Just read the second comment on the link you provided and you have the answer.
  • TheLoneWolfling 11y ago
    > Nowaday’s fast Class 10 cards achieve their high read and write speeds only by buffering in advance, assuming that the subsequent blocks will be read or written next. That means they inevitably sacrifice random read and write speeds. This effect is in the order of several magnitudes. For instance, a card with sequential read and write speeds of 10 MB/s might collapse to just 0.01 MB/s for random access. Yow. Yet another example of over-optimization to benchmarks. ...Except that, even then, how exactly is appending to a log file repeatedly random access? Bad journaling?
    • trendandbeyond 11y ago
      Test
    • tjoff 11y ago
      This is much closer to random access than sequential access. Counter question: How is appending to a log file repeatedly sequential access? No meta data or other interaction required? Surely the sequential writes benefit from larger buffers? Not to mention that the flash block is way larger than the appended message. You would need TRIM to not make that an extremely wasteful operation, not sure if the typical Pi installations make use of it but a quick google seems to indicate that it at least has been a problem. So writing that 1 kbit now means reading a whole block, edit the content of it, and writing that whole block back - which is hardly sequential either. 1 Mbit/s is starting to seem pretty fast. The only pathological case here is the "not optimal sequential write case", which sure is enough to kill any random USB-thumbdrive or SD-card. Just copying two files two a thumdrive at once can kill performance by an order of magnitude compared to doing them one after another.
      • TheLoneWolfling 11y ago
        This is where you benefit by having a file system (or disk controller) that isn't brain-dead. Unfortunately, it seems like both the controller and file system are brain-dead on the RPi. Namely, you have a cache that detects this sort of (relatively-common) append-only operation, and buffers it until it makes sense to actually write it (either because the disk is otherwise unoccupied or because you are close to the limits of your power buffer). Alternatively, you have a file system that actually knows the advantages and limitations of flash. You can do append-only files efficiently on flash (without doing all of the read + write dance). "All" you need to do is take advantage of a bit of scratch space and knowing how flash works. Namely that you don't necessarily need to flash a block to write to it, as long as you are only turning zeros to ones (or vice versa, depending on how physical bits are mapped to logical bits. Multilevel flash is a little more complex, but still doable). (For instance, instead of having one filestamp, you have space for 16 filestamps, with two bytes at the beginning, all initially set to all zeros. You check the last bit set and use that filestamp. Congratulations, you now can update the file 16 times before needing to reflash the block. If that's not enough, you can extend it arbitrarily (note that you can do this dynamically for files only when they are updated enough to warrant it!) And metadata/etc can be done in the same way. For something like a log file, you have, say, 16 slots for how much of the block is occupied, and a pointer to the next block (or null). You append the content of the new log line to the file and add the new content. One write, no blocks being flashed. (Two writes if/when you run out of space in the block.) See, for instance, https://github.com/bnahill/FLogFS/ https://github.com/bnahill/FLogFS/ or https://en.wikipedia.org/wiki/F2FS/ https://en.wikipedia.org/wiki/F2FS/