read-only root? Продолжение борьбы с лишней записью на ssd, а также нубовопросы

Половины будет хватит всем.

когда возникает большее IO на чтении ? кэш браузера использует свою БД, потому тут IO на чтение не увеличивается

вот если использует свою БД, то запись/чтение идёт в эту БД.

Ну а если ты эту БД выкинул в память, то тебе придётся раз создавать БД с нуля.

Т.е. вместо апдейта одного inode тебе придётся править блоки нескольких файлов.

важно иметь на нём много свободного места

в гигабайтах сколько ?

занято должно быть не более 70%. И это не только моё мнение. В Сети даже рекомендуют отпиливать от SSD неиспользуемый раздел, но я считаю, что это рекомендация только для маздая.

Половины будет хватит всем.

жалко половину ssd не использовать, откуда инфа ?

занято должно быть не более 70%.

хорошо бы найти графики роста/спада скорости от размера свободного места

хорошо бы найти графики роста/спада скорости от размера свободного места

ты их сам можешь построить. Ну например считая, что запись блока в 4К занимает 10мкс (точные цифры см. в спеках), а стирать можно только за 1000мкс, и только островом из 64х блоков.

Т.е, когда у тебя кончаться чистые острова, тебе нужно ВНЕЗАПНО стереть остров. Но:

1. остров стирать в 100 раз дольше, чем писать

2. не каждый остров можно стереть, т.к. если SSD забит сильно, то на острове будут не только ненужные, но и нужные блоки. Потому, тебе перед стиранием придётся переписать некоторые блоки с острова в другое место.

3. п2 следует применять рекурсивно, т.к. тебе нужно куда-то писать, а места у тебя УЖЕ нет.

ЗЫЖ потому так важна сборка мусора им команда TRIM(которая как раз и указывает SSD, что является мусором). Если всегда есть много свободных островов, то все записи распределяются между ними, и потому износ минимален, а скорость максимальна. При этом и то и другое на порядок выше, чем у любого HDD.

Это была хорошая новость. Плохая в том, что идеальные условия бывают не всегда.

PS: IRL, если у тебя включен atime, если у тебя ведутся логи на SSD, и если у тебя кеши для /var/tmp/ и прочих таких «аватарок», которые меняются редко, но читать надо постоянно, или придётся качать/считать заново, то у тебя объём (пере)записанных блоков небольшой, и IRL для этого выделяется 3.5 острова, куда всё и пишется весь день. К вечеру выделяется другие 3.5 острова, а старые за ночь очищаются. Таким образом, за сутки ты юзаешь 3.5 острова, а так как их Over9000, то тебе хватит этого на Over7лет(>2571день), если один остров ты можешь стереть всего лишь один раз, а после второго цикла стирания он умирает. Через 7 лет у тебя по любому останется в живых >95% блоков. Математическая статистика тебе в помощь.

К вечеру выделяется другие 3.5 острова

это в среднем. IRL вечера бывают разные, и в некоторые вечера нужно больше островов. Статистически ничего не меняется тогда, и только тогда, когда свободные острова есть с вероятностью 95%. Ежели их нет, то их придётся делать, что в нашем случае приведёт к смерти многих блоков(напомню, в моей модели стирать можно всего один раз). Даже при статистически равномерном использовании, таких вечеров будет около 5%(т.е. каждый двадцатый), что приведёт не к долгой жизни в 2571 день с 5% отказов, а к смерти за пару-тройку месяцев(математическое ожидание смерти менее 60и суток, если считать смертью заметно большее 5% число мёртвых блоков).