атомарность записи сектора на SSD

HDD гарантируют атомарность записи сектора при отключении питания

за счет накопленной энергии вращения блинов

как с этим у SSD, гарантируется ли это?

не вижу проблем гарантировать это за счет накопленой энергии конденсаторами, но утверждать не берусь :)

вот и я утверждать не берусь хотя понимаю необходимость этого для ведения журналов, хотелось бы каких то пруфов от людей в теме

за счет накопленной энергии вращения блинов

там еще и головка паркуется, конденсаторы энергию дают

хотелось бы каких то пруфов от людей в теме

я совсем не в теме SSD

http://web.cs.ucla.edu/classes/fall13/cs111/scribe/13b/index.html

In Understanding the Robustness of SSDs under Power Fault by Zheng et al. at FAST '13

Out of 15 SSDs, only 2 worked when they cut the power

....

Summary: Even though SSDs can do more operations after a power failure, they have more problems because their high performance involves parallel writes, wear-levelling, etc.

Во-первых, для гарантированной записи данных требуется выполнить flush на уровне диска (команда Force Unit Access (FUA) и т.п.). До flush ничего не гарантируется (ибо NCQ и внутренний кэш), если это явно не оговорено где-то для конкретной модели.

Далее, как HDD, так и SSD, делаться на разные классы использования, условно «домашние» и «промышленные», что отражается на цене. У каких-то производителей это явное деление, у других завуалированное.

Но суть в том, что «промышленные» диски обеспечивают сохранность носителя и (иногда) даже запись всей принятой очереди. А «домашние» примерно нет, и иногда «мелким шрифтом» явно указывается что они могут повредить носитель при неожиданном отключении питания.

Поэтому «атомарность записи сектора» зависит от диска. Кстати реальный размер физического сектора может быть сильно больше 512: часто 4К, реже 8К или даже 32К.

Хуже того, некоторые домашние диски игнорируют flush-команды (тупо ничего не делают) ради производительности.

На всякий - парковка головок HDD выполняется для сохранности поверхности и самих головок, это не имеет отношения к записи.

Но суть в том, что «промышленные» диски обеспечивают сохранность носителя и (иногда) даже запись всей принятой очереди. А «домашние» примерно нет, и иногда «мелким шрифтом» явно указывается что они могут повредить носитель при неожиданном отключении питания.

На всякий сразу поправлюсь - тут имелось в виду логическое «повреждение носителя», т.е. когда начали писать и не закончили (CRC не сходится и т.п.)

Однако, некоторые неудачно выключенные SSD умеют потерять все данные. Впрочем как и HDD c некоторой вероятностью (например если головки «застрянут» и упадут на поверхность.

только имея такие гарантии можно строить надежные журналируемые хранилища

а так ли нужна ли эта гарантия ?
я хз, т.к. спрашиваю )

Однако, некоторые неудачно выключенные SSD умеют потерять все данные. Впрочем как и HDD c некоторой вероятностью (например если головки «застрянут» и упадут на поверхность.

а можно поподробнее про эти варианты.

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

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

разверни мысль, как тут может быть потеря ВСЕЙ информации ??

только имея такие гарантии можно строить надежные журналируемые хранилища

а так ли нужна ли эта гарантия ?
я хз, т.к. спрашиваю )

Без гарантии вам нужно несколько копий и поддержка консенсуса. А как говорится «консенсуса на всех не напасешься» (в этой шутке есть доля шутки).

Однако, некоторые неудачно выключенные SSD умеют потерять все данные. Впрочем как и HDD c некоторой вероятностью (например если головки «застрянут» и упадут на поверхность.

а можно поподробнее про эти варианты.

Вы не можете это контролировать (говно просто случается), поэтому не заморачивайтесь.

В SSD в прошивке контроллера может быть какое-то логическое упущение или просто ошибка. Обязательств об их отсутствии ведь никто не берет.

C HDD бывают странности как со всей механикой. То смазка почему-то стала гуще, то метал чуток задрался и трение увеличилось - случается редко и толком никто не знает почему.

Добавьте сюда проблемы с электронными компонентами, особенно с полярными/электролитическими конденсаторами - могут высохнуть с падением емкости, или в самый нужный момент контакт с фольгой нарушиться (с отключением конденсатора). Соответственно предусмотренного запаса энергии не будет, и её физически не хватит на завершение записи.

гарантия сохранности яиц, лежащих в одной корзинке, тоже не 100% :)
несколько копий данных на разных физических носителях, расположенных в разных географически местах, дают гарантию сохранности практически неотличимую от 100%.

Без гарантии вам нужно несколько копий и поддержка консенсуса.

Контрольные суммы тут не помогут ?

дык это форс-мажор и он есть всегда, вплоть до дяди Вани сантехника, с похмелья повернувшего не тот кран и сделавшего море-акиянъ в серверной. иль Зевсу чем-нить не угодил и тот шмальнул в цод не согласовав воздействие со СНиПом.
я думал чтото реальное.

Не гарантируется в общем случае. Серверные диски могут гарантировать. Рекомендуется использовать ИБП.

гарантия сохранности яиц, лежащих в одной корзинке, тоже не 100% :)
несколько копий данных на разных физических носителях, расположенных в разных географически местах, дают гарантию
сохранности практически неотличимую от 100%.

Это когда вы раз в сутки бакапы делаете. А если 1000 транзакций в секунды, то нужно еще понять какая версия данных верная/согласованная. Соответственно кворум+консенсус.

Без гарантии вам нужно несколько копий и поддержка консенсуса.

Контрольные суммы тут не помогут ?

https://habr.com/ru/post/222825/ со строки «Для начала нужно понять проблему...»

Для начала нужно понять проблему

после пары прочтений я не понял сути )
но почему контрольные суммы не помогут ?
есть же ZFS, которая их использует https://habr.com/ru/post/334596/ (как именно код я не смотрел)

Во-первых, для гарантированной записи данных требуется выполнить flush на уровне диска

понятно что предполагается что приложение сделало write и fsync. подозреваю что диск только уведомляется командой о сбросе конкретного сектора из внутреннего кеша на блин и вероятней всего тут же происходит выход из fsync и передача управления программе. может я конечно не прав и современные диски еще и уведомляют о успешном сбросе кеша и только после этого идет выход из fsync?

может при потере питания просто весь внутренний кеш записывается?

На всякий - парковка головок HDD выполняется для сохранности поверхности и самих головок, это не имеет отношения к записи.

я это к тому что энергия есть после потери питания

а так ли нужна ли эта гарантия ?

ну по идее мы можем сначала писать в журнал запись с контрольной суммой и делать fsync и только после этого делать какие-то изменения которые то-же подкреплять контрольной суммой. как минимум нужна гарантия выполнения fsync() - если уж управление вернулось то данные гарантировано зафиксированы и не подвержены падениб питания

подозреваю что диск только уведомляется командой о сбросе конкретного сектора из внутреннего кеша на блин

Нет, о конкретном секторе никто не уведомляет.

У современных дисков есть NCQ, а также команды WRITE и FUA (force unit access, примерно как flush). В общем случае WRITE читает данные из памяти хоста через DMA во внутренний write-back кэш, который записывается на носитель асинхронно и в любом порядке. В свою очередь FUA заставляет вытолкнуть весь write-back кэш на носитель, т.е. FUA равнозначна https://en.wikipedia.org/wiki/Write_barrier. Хост может получать уведомления от диска о завершении каждой команды.

и вероятней всего тут же происходит выход из fsync и передача управления программе. может я конечно не прав и современные диски еще и уведомляют о успешном сбросе кеша и только после этого идет выход из fsync?

Уведомления о завершении WRITE означают что больше не нужны подготовленные в памяти данные. Уведомления о завершении FUA означает что данные всех предыдущих команд WRITE зафиксированы на носителе.

Эти уведомления обрабатываются драйвером блочного устройства, который может быть «слоеным» (например программный RAID или https://ru.wikipedia.org/wiki/DRBD).

Затем к I/O-scheduler, затем к драйверу файловой системы, затем в коечном счете происходит выход из fdatasync/fsync/sync в исходный процесс.

может при потере питания просто весь внутренний кеш записывается?

Может, но не обязан. Зависит от диска, и если «да», то производитель где-то этим хвастается. Большинство дисков просто прерывают операцию записи в ближайшей точке логической и/или физической целостности носителя.

гарантия выполнения fsync()

в кэш память диска данные будут перенесены, не более https://habr.com/ru/company/piter/blog/436986/

я бы почитал как сделан zfs, и/или код бы посмотрел

только имея такие гарантии можно строить надежные журналируемые хранилища

Нет конечно. Достаточно гарантии что в определённый момент все записи легли на диск (т.е. что fsync работает), а потом достаточно записать 1 бит чтобы пометить эти данные как потребные для использования.

Вообще же у SSD минимальная единица записи - страница, это намного больше одного сектора и возможно больше страницы памяти (может быть 8K). И учитывая как там происходит удаление (блоками намного больше страницы) до перезапись отдельных страниц, по сути, запись из в отдельные свободные блоки, никак не связанные с положением старых данных. И том где находится какая страница нужно вести учёт. И для этого SSD не обойтись без собственного механизма повторяющего описанный выше (и возможно реализованный аппаратно вообще на другом типе памяти), а при его наличии автоматически обеспечивается и атомарность и синхронизация для запросов извне.

гарантия выполнения fsync()

в кэш память диска данные будут перенесены, не более https://habr.com/ru/company/piter/blog/436986/

Не путайте и не пугайте народ. При fsync к блочному драйверу, так или иначе, придет REQ_FUA, который к диску полетит как FUA-команда.

Другое дело (как писал выше), что консьюмер-левел диск может игнорировать FUA «ради удобства пользователя» )

я бы почитал как сделан zfs, и/или код бы посмотрел

Хорошая идея, только причем тут zfs. Начните с https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt

Вообще же у SSD минимальная единица записи - страница, это намного больше одного сектора и возможно больше страницы памяти (может быть 8K). И учитывая как там происходит удаление (блоками намного больше страницы) до перезапись отдельных страниц, по сути, запись из в отдельные свободные блоки, никак не связанные с положением старых данных. И том где находится какая страница нужно вести учёт. И для этого SSD не обойтись без собственного механизма повторяющего описанный выше (и возможно реализованный аппаратно вообще на другом типе памяти), а при его наличии автоматически обеспечивается и атомарность и синхронизация для запросов извне.

Да, всё примерно так, но с одним важным дополнением: до поступления и завершения выполнения FUA (Force Unit Access) диске не обязан ничего гарантировать, т.е. может вообще ничего не записывать и/или внезапно потерять все «грязные» данные.

надежные журналируемые хранилища

Я не сильно в теме, но разве не для этого придумали SATA/SCSI/RAID контроллеры с батарейкой за много денег?

Да, если диск с PLP.

всё неверно.

Ни один накопитель не дает тебе никаких гарантий вообще.

Т.е. сегодня все варианты хранения данных в принципе не обсуждают 100% надежности, потому что это исключительно маркетинговый треп.

Есть такие способы _увеличить_ надежность хранения:

1) записать на диск с помощью write 2) засинкать буфер vfs с помощью sync 3) прочитать данные с диска с помощью read 4) убедиться что данные считаны не из памяти, а с диска с помощью minmap 5) понять, что всё это несущественная фигня и перейти к кворумной записи 6) отправить команду записи на 3 сервера 7) опросить 3 сервера о результах записи 8) понять, что этого хватает для большинства практических задач

А вот эта атомарность харда — вообще не рассчитывай на это.

что бы разводить сисадминов на бюджет IT подразделения

Нет никой атомарности. Хочешь гарантию - сделай сам.
Оракл, насколько я помню, хранит заголовок в начале и в конце каждого сектора. Если они совпадают, то сектор записался полностью, гарантия 100%.

что бы разводить сисадминов на бюджет IT подразделения

Я правильно понимаю намёк — «батарейка бесполезна»? Если нет, прошу пояснить суть.

1) аппаратные рейды медленнее софтверных 2) батарейка может быть и несет пользу, но сегодня принято думать о том, что будет, если сдохнет и батарейка, и контроллер, и сервер. А как только ты начинаешь писать на второй сервер, выясняется, что рейд не нужен 3) интереса ради: возьми 5 хардов по 14 терабайт, дай им нагрузку и почисти один из них. Посмотри сколько будет перестраиваться рейд. Сохранит ли система работоспособность на это время.

Да, батарейка теряет свою актуальность, которая была в односерверную эпоху

Т.е. сегодня все варианты хранения данных в принципе не обсуждают 100% надежности, потому что это исключительно маркетинговый треп.

EMC сделала прекурсор UNITY (линуксовый порт VNX2) с официальным DU/DL (data unavailable/data lost) рейтом 99.999%. На самом деле, там все шесть девяток было по всем проданным массивам, но не стали публиковать, т.к. это красная тряпка для всяких Гартнеров и СториджРевью, которые сразу начнут бензопилой лом пилить и т.п.

Самое удивительное для меня было, что эти кипы замшелого говнокода (то самое «энтерпрайз качество») вылизали до такого блеска, благодаря одним лишь жёстким процессам тестирования и релиза. Ну и меньше десятка талантливых программеров, которые самые злобные баги смогли найти и поправить. И была архитектура железа и софта, рассчитанная на падёжь. Без правильной архитектуры DU/DL хуже даже при хорошем коде.

EMC сделала прекурсор UNITY (линуксовый порт VNX2)

«Пусть кушают пирожные!» (С)

Ни на то ни на другое у ТС-а тупо не хватит бабла :( Ибо если бы хватало - он бы не С этот Т ;-)

ну да. Один сервер с 3 независимыми процессорами (каждый из которых на своей материнке со своей памятью), 6 независимыми сетевыми картами, 3-мя независимыми наборами дисков, клиент который умеет ходить по 15 разным айпишникам.

Но всё это всё ещё называется одним стораджем =)

Но всё это всё ещё называется одним стораджем =)

Но он же один? :) И 99.9999% - это 32 секунды даунтайма в год.

99.9999% - это 32 секунды даунтайма

Не 1 мегабайт из каждого терабайта?

Как unity может быть пять девяток, если это такое же древнее active/passive говно, как и vnx? С 20ти летней архитектурой и корявым ми[мо]крокодом, и, вдобавок, производительностью даже хуже, чем у самого vnx.

Как unity может быть пять девяток, если это такое же древнее active/passive говно, как и vnx? С 20ти летней архитектурой и корявым ми[мо]крокодом, и, вдобавок, производительностью даже хуже, чем у самого vnx.

active/active оно. Да, даты в исходничках, порой, радовали.

Производительность плюс-минус такая же, если одинаковые фичи на похожем железе сравнивать.

Архитектура старая, зато проверенная. Клиентские данные не теряет, в отличие от с большой помпой купленного стартапа ;)

active/active

Только в мечтах емсишных марктелогов (они у них конечно круты, любое говно хайпанут так, что многие бегут покупать не читая реальных спеков), а в современном мире, даже адепты емси, соглашаются, что говно это, а не active/active.

Архитектура старая, зато проверенная

Есть одно маленькое «но» - эта старая архитектура не рассчитана на нынешние скорости передачи и ssd там, как мёртвому припарки.

Клиентские данные не теряет

На прошлой галере при апдейте микрокода одного из unity данные восстанавливали с бэкапа, пробный апдейт делал инженер емси, который приезжал обновлять и расширять наши xtreme-io (первый экстрим тоже благополучно про€бал все данные, хотя было клятвенно заверено, что в мажорной обнове эта процедура больше не disruptive, после чего обновления отложили, а емцэ не выгнали ссаными тряпками только потому, что те сделали очень большие скидки на все текущие контракты и на последующие закупки в течении нескольких лет, ну и контора та еврейская была)

Только в мечтах емсишных марктелогов (они у них конечно круты, любое говно хайпанут так, что многие бегут покупать не читая реальных спеков), а в современном мире, даже адепты емси, соглашаются, что говно это, а не active/active.

Ну что ты говоришь, Юнити (и предшествующий Киттихок) - актив-актив, работают обе головы.

Есть одно маленькое «но» - эта старая архитектура не рассчитана на нынешние скорости передачи и ssd там, как мёртвому припарки.

Разумеется. От SSD припарки есть, а вот NVMe уже не поможет.

На прошлой галере при апдейте микрокода одного из unity данные восстанавливали с бэкапа

И я помню этот баг :)

пробный апдейт делал инженер емси, который приезжал обновлять и расширять наши xtreme-io (первый экстрим тоже благополучно про€бал все данные, хотя было клятвенно заверено, что в мажорной обнове эта процедура больше не disruptive, после чего обновления отложили, а емцэ не выгнали ссаными тряпками только потому, что те сделали очень большие скидки на все текущие контракты и на последующие закупки в течении нескольких лет, ну и контора та еврейская была)

Вот я про них и говорил. Причём, там не только при апдейте, а просто во время эксплуатации случалось. Чего со старым говном с точки зрения потребителя никогда не случалось (с точки зрения девелоперов, которым вся статистика с сотен тыщ проданных ящиков льётся - случалось, но процент мизерный). Поэтому 30-летняя архитектура до сих пор живёт: заменить не чем.

актив-актив, работают обе головы.

То, что они работают обе, ещё ни о чём не говорит, тем-более это возможно только когда у тебя райд-группы не в пуле, также привязка к sp и порту и доступ к лункам только через привязанный sp, really dude? Это НЕ active/active - это на€балово. Посмотри, как это реализовано у хитачи, и узри уже, что юнити - говно, какое ещё поискать.

От SSD припарки есть

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

Поэтому 30-летняя архитектура до сих пор живёт: заменить не чем.

Это точно не про юнити и, прости хоспаде, vnx. У емц есть ровно одна хорошая линейка и имя ей symm(ныне vmax).

А вот эта атомарность харда — вообще не рассчитывай на это

https://www.mram-info.com/ibm-introduces-its-latest-192tb-enterprise-ssd-driv...

То, что они работают обе, ещё ни о чём не говорит, тем-более это возможно только когда у тебя райд-группы не в пуле, также привязка к sp и порту и доступ к лункам только через привязанный sp, really dude? Это НЕ active/active - это на€балово.

IO можно спокойно слать на обе головы одновременно.

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

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

IO можно спокойно слать на обе головы одновременно.

при чём здесь слать на обе головы? io также спокойно пойдёт сначала на sp который владеет этой lun, а уже потом на диски. я про internal data path, если что, со стороны хоста действительно пофиг куда слать.

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

я бы ещё понял дедуп, но компрессию, впрочем, я уже не удивляюсь.

при чём здесь слать на обе головы? io также спокойно пойдёт сначала на sp который владеет этой lun, а уже потом на диски. я про internal data path, если что, со стороны хоста действительно пофиг куда слать.

Тогда я не пойму, что вам не нравится? Единственный минус здесь - ALUA.

Как там у Хитачи сделано - я не знаю. LUN owner у многих сделано.

я бы ещё понял дедуп, но компрессию, впрочем, я уже не удивляюсь.

Дедуп просто сделать (непросто сделать его быстрым и с большим коэффициентом). Резальтат успешного дедупа - увеличение референс каунта. Результат компрессии - блок меньшего размера, который на диск 1-в-1 положить нельзя, плюс нужно держать развесистую метадату для трансляции LBA.

ALUA

вот этим и не нравится. и не только мне.

LUN owner у многих сделано.

и это как-то делает юнити не говном? я в курсе, что у многих так, но есть и нормальные производители.

Дедуп просто сделать

ой-вей, да што ви говогите. так-то что угодно просто сделать, только потом начинается «непросто сделать его блаблабла»

плюс нужно держать развесистую метадату для трансляции LBA

а для дедупа ddt не надо держать, ну ок, чо.

блок меньшего размера, который на диск 1-в-1 положить нельзя

а ты точно настоящий сварщик?

а для дедупа ddt не надо держать, ну ок, чо.

Если thin provisioning уже есть, то для дедупа ещё один уровень индирекции не нужен. Для компрессии нужен.