← Back to context Comment by marcan_42 4 years ago On this NVMe, flushing is slower than on some spinning disks, so it apparently matters. 2 comments marcan_42 Reply shellac 4 years ago Yes, I would have skipped the fsync thing, which carries a lot of baggage, and concentrate on this.Btw, are you sure those spinning disks are actually flushing to rust? Caches all the way down... ;-) marcan_42 4 years ago I mean, typical seek time on rust is O(10ms) and these controllers are spending 20ms flushing a few sectors. Obviously rust would do worse if you have the cache full of random writes, though. The problem here is the huge base cost.
shellac 4 years ago Yes, I would have skipped the fsync thing, which carries a lot of baggage, and concentrate on this.Btw, are you sure those spinning disks are actually flushing to rust? Caches all the way down... ;-) marcan_42 4 years ago I mean, typical seek time on rust is O(10ms) and these controllers are spending 20ms flushing a few sectors. Obviously rust would do worse if you have the cache full of random writes, though. The problem here is the huge base cost.
marcan_42 4 years ago I mean, typical seek time on rust is O(10ms) and these controllers are spending 20ms flushing a few sectors. Obviously rust would do worse if you have the cache full of random writes, though. The problem here is the huge base cost.
Yes, I would have skipped the fsync thing, which carries a lot of baggage, and concentrate on this.
Btw, are you sure those spinning disks are actually flushing to rust? Caches all the way down... ;-)
I mean, typical seek time on rust is O(10ms) and these controllers are spending 20ms flushing a few sectors. Obviously rust would do worse if you have the cache full of random writes, though. The problem here is the huge base cost.