2 ms·
if you have implemented fsync() to not sync to actual backing storage you have a bug in your design. That is orthogonal to caching the writes in RAM prior.
by rowanG077 7y ago
if you have implemented fsync() to not sync to actual backing storage you have a bug in your design. That is orthogonal to caching the writes in RAM prior.
- pjc50 7y agoSure, but for this use case if you're doing a set of database transactions each will be its own write to persistent storage. Which is why you care about the random 4k write speed. "Sequential writes are much faster than random writes" is not at all a new problem, it dates from the hard disk era. Which is why most filesystems will cache as much as they think they can get away with.
- cmurf 7y agoWhen I do OS updates (Fedora, so that's dnf and rpm) with a system on USB flash or SD Card flash, the write are abysmal. Like, 3-4MB/s, using `iotop -d3 -o`. There's almost no reads suggesting the RPMs that have been downloaded are cached. I experience this with ext4, btrfs, and f2fs. Using strace on both dnf and rpm, there's no appreciable amount of sync(), fsync(), or fdatasync() - so I'm not really sure why there was this persistent ~4MB/s trickle to the card rather than large "state" updates, in particular for f2fs and Btrfs. All three make heavy use of delayed allocation, but in particular f2fs and Btrfs have no specifically designated locations for write, or overwrites. So I'd expect that most update OS type writes should/could be much faster. A sequential write is ~20MB/s on both of these media, and sequential reads are ~150MB/s. I wasn't ever able to profile it well enough to understand why it's so dog slow.