LINUX.ORG.RU

Кто-нибудь может на пальцах объяснить, что такое zns ssd?

 , , , ,


1

2

Subj

Компания SK Hynix сообщила, что до конца текущего года завершит разработку SSD-накопителей с поддержкой технологии зональной записи однотипных данных ― Zone Namespaces (ZNS). Технология ZNS относится к категории открытых, но SK Hynix обещает стать первым производителем твердотельных накопителей, которые будут её поддерживать. Такие накопители, судя всего ― на стороне удалённых хранилищ данных и в облаках, позволят записывать музыку, видео и изображения в свои собственные зоны на одном и том же SSD.

Коммерческие поставки SSD SK Hynix с поддержкой зональной записи данных начнутся в первой половине следующего года. Компания готовит 2-ТБ SSD в виде PCIe 3.0 карты и накопитель в формфакторе M.2 22110. Обе модели будут базироваться на 512-Гбит 72-слойной памяти 3D NAND TLC. Как заявляют в SK Hynix, поддержка технологии ZNS увеличит скорость работы с данными на 30 % и в четыре раза повысит устойчивость SSD к износу. Последовательная запись однотипных данных, как уверены разработчики технологии Zone Namespaces, уменьшит частоту очистки ячеек памяти, включая сокращение операций по сбору мусора до нуля. С зонами можно будет работать целиком, а не с отдельными файлами, что также снизит операции по очистке SSD.

Появится ли технология ZNS в домашних системах? Возможно, в специализированных программах для обработки изображений, видео и звука. Почему бы и нет? Ведь она фактически программная.

★★

Ответ на: комментарий от ncrmnt

Полистал презентацию. Обратило на себя внимание

File-system with SMR support (f2fs, btrfs)

И на каждом шагу аббревиатуры ZAC/ZBC

Reuse existing work already applied with for ZAC/ZBC hard-drives (SMR)

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


https://lwn.net/Articles/697913/
Block layer support ZAC/ZBC commands

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от greenman

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

Для увеличения плотности записи, шоп объем побольше сделать.

kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Увеличение плотности без особых изменений железа эквивалентно удешевлению.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от greenman

Увеличение плотности без особых изменений железа эквивалентно удешевлению.

Не совсем. Диски могут хранить больше, но при этом скорость перезаписи от этого страдает. То есть они довольно узкоспециализированными окажутся, и стоимость упадет не так сильно, как хотелось бы.

kirk_johnson ★★ ()
Ответ на: комментарий от kirk_johnson

SMR диски дешевле (на терабайт), с более низкой скоростью записи. Никаких противоречий не вижу.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)

Тег smr был бы очень уместен

Насколько я понял, в последние годы в линуксе была добавлена поддержка SMR дисков. Раз уж такая поддержка есть, то производители дисков задумались – а нельзя ли как ещё использовать найденные решения. И предложили использовать эту зональную запись в ssd. В принципе логично. Основной минус, с моей точки зрения, в том, что всё это образует ещё один слой усложнения. Чем система более сложна – тем больше вероятность ошибки. Недавний баг с blk-mq тому подтверждением.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 3)

Прочитал первую половину ОП, описываемое похоже на дедупликацию данных.

torvn77 ★★★★ ()

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

Eof ()
Ответ на: комментарий от greenman

Да, но изменения-то есть. Вместо того чтобы мочь записывать в произвольный LBA (4к), диск умеет в две операции: «сотри вот эту зону размером 256 мегабайт» и «допиши вот эти байты в эту зону, начиная с первого байта в зоне, в который еще не писали».

Это сильно меняет подход к хранению данных: вы не можете дешево поменять условный байтик в середине SQLite-базы, но зато, если ваш софт поддерживает SMR, на один диск можно уложить гораздо больше логов, будь до доступа, или транзакционных.

Arrest ()
Ответ на: комментарий от Arrest

если ваш софт поддерживает SMR, на один диск можно уложить гораздо больше логов

А если софт не поддерживает SMR, то нельзя гораздо больше?

greenman ★★★★★ ()
Ответ на: комментарий от greenman

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

Если софт не поддерживает (совсем), то вы не сможете пользоваться таким диском.

Если где-то внизу стека эмулируется обычная семантика жесткого диска (т. н. drive-managed SMR, или ара-тюнинг традиционных файловым системам а-ля ext4), то при попытке пользоваться им как обычным диском производительность либо падает до единиц мегабайт в секунду на запись, либо перестает быть предсказуемой.

Если где-то чуть повыше есть более правильное понимание того как правильно писать на такие диски (на уровне F2FS+dm-zoned), то производительность на запись файлов практически не проседает по сравнению с обычными дисками. Но вот потом удалять небольшие файлы очень больно...

А если у пользовательского софта подходящая структура хранения данных (append-only, или данные можно разбить на чанки большого размера, удаления только большими чанками), и он сам знает как обращаться с такими дисками, то ему будет норм.

Arrest ()
Ответ на: комментарий от Arrest

небольшие файлы

Это какого примерно размера?

tiinn ★★ ()
Ответ на: комментарий от tiinn

Правильнее, конечно, было сказать что файлы удалять дешево, но писать на освободившееся место очень дорого, потому что нужно целиком перезаписывать все 256 мегабайт зоны.

Самый патологический случай — это если у вас диск заполнен целиком, и каждую зону занимает сначала один большой файл, а потом один маленький, и вы удаляете все большие. В реальности так никто не делает, так что чаще неприятности будут случаться на чем-нибудь в духе «мы удалили много более-менее случайных файлов <200 мегабайт, а потом решили записать заново».

Если вы помните из начала 2000-х такие слова как «дефрагментация» и «размер кластера», а из начала 2010-х выражение «SSD write amplification» — вот это как раз про SMR-диски, только масштабы больше.

Arrest ()
Ответ на: комментарий от Arrest

Если софт не поддерживает (совсем), то вы не сможете пользоваться таким диском.

Бывают SMR диски, которые не могут работать как обычные (пусть и медленно)?

это если у вас диск заполнен целиком

Но на диске должен быть PMR кэш? Или и он не спасает?

greenman ★★★★★ ()
Ответ на: комментарий от Arrest

Если вы помните из начала 2000-х такие слова как «дефрагментация» и «размер кластера», а из начала 2010-х выражение «SSD write amplification»

А, теперь понятно

tiinn ★★ ()
Ответ на: комментарий от greenman

Бывают SMR диски, которые не могут работать как обычные (пусть и медленно)?

Да, это называется host-managed SMR. WD DC HC6xx, например.

Но на диске должен быть PMR кэш? Или и он не спасает?

Зависит от чего спасать. От небольшого количества записи типа метаданных ФС помогает, от перезаписи большей части диска — нет. Посмотрите на презенташку https://events.static.linuxfound.org/sites/events/files/slides/lemoal-Linux-S..., особенно страницы про dm-zoned с 16 по 21 — там не очень честный жесткий диск (PMR с прошивкой, косящей под host-managed SMR с 1% conventional зон), но dm-zoned поверх делает ровно то о чем вы говорите: кэширует случайные записи в PMR-регионе, а потом сбрасывает их в зоны с последовательной записью. Видно что первое время на диск можно писать со скоростью не уступающей обычному диску, но когда кэш кончается, скорость резко падает.

Arrest ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)