Надо раскуривать вот это: https://www.usenix.org/conference/vault19/presentation/bjorling

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

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

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

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

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

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

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

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

Достаточно интересно про SMR

https://www.snia.org/sites/default/files/SDC15_presentations/smr/StephenMorgan-An_SMR-Aware_Append_Only-FiveSystem.pdf

https://events.static.linuxfound.org/sites/events/files/slides/lemoal-Linux-SMR-vault-2017.pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бывают 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-регионе, а потом сбрасывает их в зоны с последовательной записью. Видно что первое время на диск можно писать со скоростью не уступающей обычному диску, но когда кэш кончается, скорость резко падает.