Back of the napkin: venti(8) has an index entry as 40 bytes. That would fill a 1MB erasure block in 25k writes. A SLC should handle at least twice that. A MLC is probably less than half that from what I understand. But we haven't discussed wear levelling yet. With the index recommended to be 5% of the data size there should be plenty of data blocks with write cycles left for the SSD to wear level with. I wouldn't worry about it. The 128MB case however is pretty bad. It'll take 3,200k writes. Given the data blocks, following the 4k assumption from the manual, will fill a 128MB block in 32k writes that could kill a cheap low write capacity SSD just with the data blocks. My cursory conclusion; back of the napkin, index behaviour is not ideal but shouldn't cause any issues for regular wear levelling SSD (which is all of them now right?) with a few MB erasure blocks. But going beyond that size and yeah... Ouch. But that's just small index updates and large erasure block SSDs for you. Transactional databases doing lots of small updates are also known for being able to kill SSDs. As I understand it common practice is to over provision a transactional database SSD to make up for it. On Sun, 26 May 2024, 20:40 , wrote: > I would like to refresh my questions from may 4th. > > Can it be the case that the venti index file exhibits a desastrous write > pattern for SSDs? > > I presume that each new block written to venti causes a random block to > be rewritten in the index file, until the bucket is full (after 215 > writes). Given, that the erasure blocks in the SSD may be of size 1MB or > even 128MB, each such write may be a big strain on the device. > > Any opinions? > *9fans * / 9fans / see discussions > + participants > + delivery options > Permalink > > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2ca67486c7a13a77-Mccab748b1a801a2849a72e6e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription