3 ms·
> and will reuse them when it reaches the end of the file? You were right up till that - it reuses pages as soon as they are safe to reuse, not waiting to get
by hyc_symas 12y ago
> and will reuse them when it reaches the end of the file?
You were right up till that - it reuses pages as soon as they are safe to reuse, not waiting to get to the end of the file.
Anyway, yes, write amplification is a significant factor, in any DB design.
- eloff 12y agoWhile I have your attention, assuming SSD with typical 128k erase blocks, do you do anything special to avoid write amplification at the disk level when reusing pages? My understanding is that those are in-place updates from the filesystem's POV, so writing over 32k of old pages will cause 128-256k actual writes. One could avoid this somewhat with trim support, fallocate + hole punch (not portable) but you have to think carefully about alignments and grouping free pages into contiguous erase block multiples. That never struck me as being very practical. Have you thought about that problem before or tried anything there?
- hyc_symas 12y agoThought about it - yes. Tried anything - no. We have no idea what an SSD's FTL is doing under the covers, and no way to find out thru a SATA/SCSI command interface. Trim and hole punching are no advantage - it's not safe to do them before a page may be safely reused, as soon as a page can be safely reused, we'll probably be writing new data into it.