Действительно ли записи сектора диска являются атомарными?

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

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

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

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

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

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

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

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

См .:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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