Оставлять ли неразмеченной область пространства SSD равную объему SLC-кэша в SSD?

Question

[Alex_GDI]

Настраиваю LVM cache на SSD. В статье хабр.ком/ru/post/492834/ автор предлагает не размечать часть пространства SSD равную объему своего SLC-кэша.
Верно ли это на сегодняшний день?
Поступаете ли вы так в своих конфигурациях на продакшенах?
Спасибо.

Comments

[Fenrir89]

Если в windows через программную утилиту самого диска тогда есть смысл, в линуксе это должно работать, а по поводу sls, mls,tls,qls ниже(выше) правильно написано что техпроцесс ты в любом случае не обманешь на сжатие требуется время, тут вариант только один для повышения быстродействия не использовать слои кроме sls, т.е. ограничить объем диска так чтобы переполнение первого слоя небыло, но смысл покупать большой размер, с mls,tls,qsl нету, там скорее всего наработка времени в итоге будет меньше, итого под кеш твой выбор из sls, *sls=slc

[dorne]

Ниже все неплохо описали. В статье хабр.ком/ru/post/492834/ используются диски с динамическим SLC - кэшем который пишется другим режимом записи в те-же ячейки что и основная память. При этом, у дисков очень мало зарезервированного пространства под кэш. Так что, во-избежании деградации производительности из-за сборки мусора при заполнении SSD до 100%, мы, просто, отрезаем кусочек, чтобы SSD до 100% никогда не заполнился.

Answer 1

[15432]

А как, по-вашему, это прибавит производительности?

- Если SLC кеш выполнен в виде отдельной микросхемы (вряд ли) то он не учитывается в общем объёме SSD - резерв бессмысленный
- Если SLC кеширование выполняется в виде особого режима записи в ту же самую микросхему, но в резервную область - то эта область и так никогда не доступна пользователю, резервировать снова нет смысла
- Наконец, если SLC кеширование реально делается в свободную пользовательскую область, то этот "кеш" займёт N*8 объёма, потому что ячейки работают в SLC режиме вместо TLC - резервировать N объёма также бессмысленно.

Нужно детально читать спецификацию, делать тесты и по ним уже смотреть. Для SSD корпоративного уровня, имхо, о таком заморачиваться не стоит, производитель обо всём позаботился

Comments

[Alex_GDI]

Смотрите. В статье, которую я привёл в вопросе (я не знаю видите ли вы ссылку на неё, потому что я её нет, хотя я её вставил в вопрос в теге ссылка) автор использует SSD Samsung 860 QVO 2 TB. У этого накопителя применяется технология кеширования описанная вами в варианте 3. Но при этом выделяется контроллером для этого конкретного SSD всего лишь 78 Гбайт пространства, и автор статьи предлагает неразмечать как раз такой объём.

[Fenrir89]

Alex_GDI, ссылки нету

[Alex_GDI]

Fenrir89, хабр.ком/ru/post/492834/ раздел SATA SSD

[АртемЪ]

15432, это в первую очередь повлияет на стабильность. Скоростные характеристики будут более стабильными. Не будет просадок по скорости.

Для SSD корпоративного уровня, имхо, о таком заморачиваться не стоит, производитель обо всём позаботился

Да в основном от таких заморочек польза для SSD корпоративного уровня.

[15432]

АртемЪ, это то понятно, чем больше свободного места, тем равномернее износ и лучше по скорости, но именно равное размеру "SLC кеша" - толку мало. 25% ещё ладно там

Answer 2

[Drno]

диск сам решит лучше Вас. даже я со своим самомнение в этой ситуации полагался бы на инженеров производителя)
ненадо,моё лично мнение

Comments

[Alex_GDI]

конечно производитель знает как лучше диск должен использоваться как "диск", но в данном случае диск сам используется как кэширующее устройство для другого логического тома. И вот тут как раз у меня возникают вопросы. Какую конфликтную ситуацию вижу я: почти всё пространство диска заполняется кешируемыми данными с медленного тома -> уменьшается кэш самого диска -> получаем медленную скорость записи на QLC. Понимаете меня?

[Drno]

Alex_GDI, а понятно. но тут я думаю Вы и сами понимаете, что есть быстрый(как оперативка) кеш у диска(допустим 4 гб), как только он заполнится - пойдет запись на диск со скоростью самого диска...
Смысл - кеш у диска крайне мал (пропорционально объему диска)
У меня ССДшки тоже начинают копирование на 1,5Гб, а заканчивают 400-500мб )) (если файл выше определенного объема) Вы же делаете кеш для обычного RAID или диска?(база данных может быть? )

[Alex_GDI]

Drno, для обычного HDD. Тестовая среда, просто учу LVM.

[Drno]

Alex_GDI, ну обычно ссд в такой ситуации просто указывается как кэш без доп настроек. и использутеся по сути как "оперативка"

[Fenrir89]

Alex_GDI, почитай про технологию записи на qls ячейки, проведи тесты записи на qls(полный объем диска, а не 1гб в том же cristall mark, хорошо бы если с одинаковых дисков ssd) сравни со скоростью доступа чтения/записи с обычным hdd если будет выше смысла в дополнительном объеме не вижу, иначе ты можешь потерять именно на времени сжатии данных по глубине ячеек, если сильно упрощать каждый переход на другой из слоев уменьшает скорость записи на 2+ время на сжатие(отклик контроллера при операции сжатия ячеек), +увеличение износа ячеек
P.S. вообще вижу очень хреновоую идею использова qls как кеш, полный объем не используется либо приводит к увеличенному износу ячеек, проще взять за туже сумму slc ssd, остальное покажут тесты, да и не думаю что кеш в данном случае хотя-бы приблизительно равен hdd,
P.s.s Проще и логичнее в данном случае использовать ram диск, он более устойчив к перезаписи, и имеет сквозвую перезапись, а на ssd лучше на весь объем сделать своп, при условии не очень часто меняющихся данных

[Fenrir89]

Alex_GDI, тем более если учишь и есть тестовая среда пробуй разные варианты сравнивай результаты, хотя понимаю что на тестовой среде сложно получить достаточный поток данных что бы такую систему тестировать(довести до предела), но можно попытался завернуть дубли запросов с продакшена на тестовую среду и отправлять в /dev/null

[Alex_GDI]

Fenrir89,

смысла в дополнительном объеме не вижу, иначе ты можешь потерять именно на времени сжатии данных по глубине ячеек, если сильно упрощать каждый переход на другой из слоев уменьшает скорость записи на 2+ время на сжатие(отклик контроллера при операции сжатия ячеек)

.
Я вас не совсем понимаю. Когда вы записываете данные на SSD диск, сначала эти данные попадают в DRAM кэш (если он в есть), потом в SLC-кэш. А потом во время операции сборки мусора эти данные переписываются в другие ячейки. Верно?

[Drno]

Alex_GDI, насколь я знаю(понимаю), они встают в очередь и пишутся сразу, по мере возможности

Answer 3

[АртемЪ]

Да, оставить неразмеченную область, хорошая идея.
Только при чем тут размер SLC кэша? К тому же во многих дисках он динамический.
Размер неразмеченной области выбирают исходя из нагрузки, а не приравнивают к кэшу. Какой объем непрерывной записи предполагается?

Суть неразмеченной области - всегда есть запас свободных ячеек, при записи не придется заниматься уборкой мусора, поэтому скорость стабильна, не важно наличие TRIM.