Дисковый сектор записывает атомарно?

Question

уточненный вопрос:

Когда ОС посылает команду записать сектор на диск, это атомарно? Т.е. запись новых данных завершается полностью или старые данные остаются нетронутыми в случае сбоя питания сразу после команды записи. Меня не волнует, что происходит при многосекторной записи - порванные страницы приемлемы.

Старый вопрос:

Скажем, у вас есть старые данные X на диске, вы записываете новые данные Y поверх него, и во время этой записи на линии электропередачи падает дерево. Без причудливого ИБП или контроллера диска с батарейным питанием вы можете получить разорванную страницу, где данные на диске - это часть Х и часть Y. Можете ли вы когда-нибудь оказаться в ситуации, когда данные на диске - это часть Х, часть Y и часть мусора?

Я пытался понять конструкцию систем ACID, таких как базы данных, и, по моему наивному мнению, firebird, который не использует журнал опережающей записи, полагает, что данная запись не уничтожит старые данные ( X) - только не в состоянии полностью записать новые данные (Y). Это означает, что если часть X перезаписывается, может быть изменена только часть X, которая перезаписывается, а не та часть X, которую мы намереваемся сохранить.

Для пояснения, это означает, что если у вас есть буфер размером с страницу, скажем, 4096 байт, заполненный половиной Y, половиной X, который мы хотим сохранить - и мы сообщаем ОС записать этот буфер поверх X, ситуация короткая серьезного сбоя диска, когда половина X, которую мы хотим сохранить, повреждена во время записи.

Answer 1

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

Проблема в том, что все лгут.

По крайней мере, когда дело доходит до базы данных, зная, когда транзакция была зафиксирована на диске, все лгут. База данных выдает команду fsync, и операционная система возвращает данные только тогда, когда все ожидающие записи были зафиксированы на диске, верно? Возможно, нет. Распространено, особенно на картах RAID и / или дисках SATA, когда вашей программе сообщают, что все зафиксировано (то есть возвращается fsync), и все же на диске еще нет данных.

Вы можете попробовать использовать DiskDhecker Брэда , чтобы выяснить, сможет ли платформа, которую вы собираетесь использовать для своей базы данных, выжить, потянув за вилку без потери данных. Суть: в случае сбоя Diskchecker платформа не безопасна для работы с базой данных. Базы данных с ACID основаны на знании того, когда транзакция была подтверждена для резервного хранилища, а когда нет. Это верно, независимо от того, использует ли база данных вход в систему с опережением записи (и если база данных возвращается к пользователю без выполнения fsync, то транзакции могут быть потеряны в случае сбоя, поэтому не следует утверждать, что она обеспечивает семантику ACID ).

В списке рассылки Postgresql есть длинная ветка, в которой обсуждается долговечность. Он начинает говорить о твердотельных накопителях, но затем попадает в диски SATA, SCSI и файловые системы. Вы можете быть удивлены, узнав, насколько ваши данные могут быть потеряны. Это хорошая тема для тех, кто нуждается в долговечности, а не только для тех, кто работает с Postgresql.

Answer 2

Похоже, никто не согласен с этим вопросом. Поэтому я потратил много времени, пытаясь ответить на различные запросы Google, пока, наконец, не нашел ответ.

от доктора Стивена Твиди, сотрудника RedHat, файловой системы ядра Linux и разработчика виртуальной памяти в лекции по ext3 (которую он разработал) расшифровка здесь . Если кто-нибудь знает, это был бы он.

«Недостаточно просто записать что-либо в журнал, потому что в журнале должна быть какая-то отметка, которая говорит: ну, (действительно, эта запись журнала) действительно ли эта запись журнала представляет собой полную согласованность с диском «И способ, которым вы это делаете, заключается в наличии некоторой атомарной операции, которая помечает эту транзакцию как завершенную на диске» [23m, 14s]

"Теперь диски в наши дни действительно дают такие гарантии. Если вы начнете операцию записи на диск, то даже если во время записи этого сектора произойдет сбой питания, на диске достаточно мощности, и он может фактически украсть мощность от энергии вращения шпинделя; у него достаточно мощности для завершения записи сектора, который записывается прямо сейчас. Во всех случаях диски дают такую ​​гарантию ». [23 м, 41 с]

Answer 3

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

К сожалению, реальная долговечность - жесткая и медленная , поскольку вам нужно сделать как минимум один полный оборот на запись или 2+ с журналированием / отменой. Это ограничивает вас несколькими сотнями транзакций БД в секунду и требует отключения кэширования записи на довольно низком уровне.

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

См:

• Как (не) добиться долговечности.
• FSync () может не записываться на диск

Answer 4

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

Из википедии (http://en.wikipedia.org/wiki/Journaling_file_system):

Некоторые диски гарантируют атомарность записи во время сбоя питания. Другие, однако, другие, может прекратить запись на полпути через сектор после потери питания, оставляя его несовпадающим с его кодом, исправляющим ошибки. Таким образом, сектор поврежден, а его содержимое потеряно. Физический журнал защищает от такого повреждения, потому что он содержит полную копию сектора,который он может воспроизвести после повреждения при следующем монтировании.

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

Из списка рассылки ядра Linux в обсуждении файловой системы журналирования ext3:

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

Я бы склонендобавьте это в комментарии к вики.На самом деле, само существование базы данных (firebird) без xlog подразумевает, что запись секторов является атомарной, что она не может скопировать данные, которые вы не хотели изменять.

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

Answer 5

Ответ на ваш первый вопрос зависит от используемого оборудования. По крайней мере, на некоторых старых аппаратных средствах ответ был положительным - сбой питания мог привести к записи мусора на диск. Однако большинство современных дисков имеют встроенный в сам диск «ИБП» - конденсатор, достаточно большой для того, чтобы достаточно долго питать диск, чтобы записывать данные из дискового кэша на диск. У них также есть схема, позволяющая определить, исправен ли источник питания, поэтому, когда питание становится нестабильным, они записывают данные в кэш на диск и игнорируют мусор, который они могут получить.

Что касается «порванной страницы», то на обычном диске принимаются только команды для записи целого сектора за раз, так что вы получите, как правило, целое число правильно записанных секторов, а остальные останутся неизменными. Однако, если вы используете логический размер страницы, который больше, чем один сектор, вы, безусловно, можете получить частично написанную страницу.

Это, однако, в основном относится к прямому соединению с обычным жестким диском с подвижным диском. Почти со всем, правила могут и часто будут отличаться. Просто для наглядного примера, если вы пишете по сети, вы в основном зависите от используемого сетевого протокола. Если вы передаете данные по TCP, данные, которые не совпадают с CRC, будут отклонены, но могут быть приняты те же данные, переданные по UDP, с тем же повреждением.

Answer 6

Я подозреваю, что это предположение неверно.

Современные жесткие диски кодируют данные в секторах - и дополнительно защищают их с помощью ECC. Поэтому вы можете в конечном итоге получить все содержимое сектора - это не будет иметь смысла при использовании кодировки.

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

Кстати, сбой ОС не приведет к повреждению данных в пределах одного сектора.

Answer 7

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

Answer 8

Я ожидаю, что одна порванная страница будет состоять из части X, части Y и части нечитаемой части. Если головка находится в середине записи сектора при сбое питания, диск должен немедленно припарковать головки, чтобы остальная часть диска (кроме этого одного сектора) оставалась неповрежденной.

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

Я читал противоречивые истории о том, сделает ли новая запись в нечитаемый сектор ее снова читабельной. Даже если ответ «да», это будут новые данные Z, ни X, ни Y.