3 ms·
It's also tricky with a COW filesystem like ZFS in which the order of data on-disk may not match the logical order of the file. So your database may decide to d
by tominous 11y ago
It's also tricky with a COW filesystem like ZFS in which the order of data on-disk may not match the logical order of the file. So your database may decide to dispatch a bunch of sequential 1MB reads to the filesystem, only for the filesystem to translate those large sequential reads into many small random 8kB reads. It depends on how fragmented the file is, so you can start off with great performance which degrades significantly over time.
Luckily SSDs have a much lower penalty for random reads compared to spinning disks, so in future this will be less of an issue.
In the meantime all you can do is use a different filesystem, hide the problem with cache, or manually defragment your data files from time to time.
- pkaye 11y agoActually SSD themselves implement COW filesystem since NAND cannot be written without erase step.
- pmalynin 11y agoWhat about TRIM?
- pkaye 11y agoTRIM is like the free() equivalent to malloc(). It releases a NAND page back to free state for other uses. It dones't require any NAND access or writes per-se but if persistent TRIM is needed (vs best effort,) it gets much more complicated.
- tominous 11y agoThat's true but not particularly relevant to database performance. As I mentioned, random reads on an SSD do not suffer from a head seek penalty so it doesn't matter how the blocks are allocated. On the other hand with spinning disk there is a huge difference in throughput for large sequential vs small random reads.