Является ли дисковый сектор атомарным?
Уточнила Вопрос:
когда ОС отправляет команду для записи сектора на диск, это атомная? т. е. запись новых данных завершается полностью или старые данные остаются нетронутыми, если сбой питания сразу после команды записи. Мне все равно, что происходит в нескольких секторах, - рваные страницы приемлемы.
Старый Вопрос:
скажем, у вас есть старые данные X на диске, вы пишете новые данные Y поверх него, и дерево падает на линию электропередачи во время этой записи. Без фантазии UPS или батареи резервного контроллера диска, вы можете в конечном итоге с разорванной страницы, где данные на диск является частью X и часть Я. Может вы когда-нибудь с ситуацией, когда данные на диск является частью X, часть Y, и часть мусора?
Я пытался понять дизайн кислотных систем, таких как базы данных, и моему наивному мышлению кажется, что firebird, который не использует журнал записи вперед, полагается на то, что данная запись не уничтожит старые данные ( X) - только не сможет полностью записать новые данные (Год.) Это означает, что если часть X перезаписывается, то может быть изменена только та часть X, которая перезаписывается, а не та часть X, которую мы намерены сохранить.
уточнить, это означает, что если у вас есть страница размером буфера, скажем 4096 байт, заполненный с половиной г, половина х, что мы хотим сохранить - и мы говорим ОС писать, что буфер по Х, нет ситуации за серьезного сбоя диска, где половина х, что мы хотим сохранить поврежден во время записи.
8 ответов
Я думаю, что разорванные страницы не проблема. Насколько мне известно, у всех накопителей достаточно энергии, чтобы закончить запись текущего сектора при сбое питания.
проблема в том, что все врут.
по крайней мере, когда дело доходит до базы данных, зная, когда сделка была совершена на диск, все врут. База данных выдает fsync, и операционная система возвращается только тогда, когда все оставшиеся записи были зафиксированы на диске, верно? Может и нет. Это распространено, особенно с RAID-картами и / или дисками SATA, для вашей программы, чтобы сказать, что все зафиксировано (то есть, fsync возвращается), и все же на диске еще нет данных.
вы можете попробовать использовать Брэд diskchecker чтобы узнать, может ли платформа, которую вы собираетесь использовать для своей базы данных, выжить, вытащив вилку без потери данных. Итог: если diskchecker терпит неудачу, платформа небезопасна для запуска базы данных. Базы данных с ACID полагаются на знание, когда транзакция была совершена для резервного хранилища, а когда это не так. Это верно независимо от того, использует ли база данных loggin с опережающей записью (и если база данных возвращается пользователю без выполнения fsync, транзакции могут быть потеряны в случае сбоя, поэтому не следует утверждать, что она предоставляет семантику ACID).
здесь длинный поток на Postgresql список рассылки обсудить долговечности. Он начинает говорить о SSDs, но затем он попадает в SATA диски, диски SCSI и файловые системы. Вы можете быть удивлены, узнав, насколько ваши данные могут быть подвержены потере. Это хороший поток для тех, у кого есть база данных, которая нуждается в долговечности, а не только для тех, кто работает с Postgresql.
кажется, никто не согласен с этим вопросом. Поэтому я потратил много времени на различные запросы Google, пока не нашел ответ.
от доктора Стивена Твиди, сотрудника RedHat и разработчика файловой системы ядра linux и виртуальной памяти в разговоре о ext3 (который он разработал) стенограмма здесь. Если кто и знает, так это он.
" недостаточно просто написать что-то в журнал, потому что в журнале должна быть какая-то отметка, которая говорит: ну, (есть ли эта запись журнала на самом деле) эта запись журнала на самом деле представляет собой полную согласованность с диском? И то, как вы это делаете, - это какая-то атомарная операция, которая помечает эту транзакцию как завершенную на диске" [23m, 14s]
"теперь, диски в эти дни на самом деле делают эти гарантии. Если вы запустите операцию записи на диск, то даже если питание не работает в середине этого сектора записи, диск имеет достаточно мощности, и он может фактически украсть питание от вращательной энергии шпинделя; она имеет достаточную силу завершить запись участка который пишется прямо сейчас. Во всех случаях диски дают такую гарантию."[23М 41С]
нет, это не так. Хуже того, диски могут лгать и говорить, что данные записываются, когда они фактически находятся в кэше диска, в настройках по умолчанию. По соображениям производительности это может быть желательно (фактическая долговечность на порядок медленнее), но это означает, что если вы потеряете питание и дисковый кэш физически не записан, ваши данные исчезнут.
реальная прочность как жесткий и медленно к сожалению, так как вам нужно сделать хотя бы один полный оборот за запись или 2+ с журналированием/отменой. Это ограничивает вас до нескольких сотен транзакций DB в секунду и требует отключения кэширования записи на довольно низком уровне.
для практических целей, однако, разница не это большое дело в большинстве случаев.
посмотреть:
люди, похоже, не согласны с тем, что происходит во время записи сектора, если питание не работает. Может быть, потому, что это зависит от используемого оборудования и даже файловой системы.
из Википедии (http://en.wikipedia.org/wiki/Journaling_file_system):
некоторые дисководы гарантируют запись атомарность во время сбоя питания. Другие, однако, могут прекратить писать на полпути через сектор после потерянный, оставляющий его несоответствующим свой код исправления ошибок. Сектор таким образом, коррумпирован и его содержимое потеряно. Физический журнал защищает от таких коррупция, потому что она содержит полную копия сектора, который он может повтор над коррупцией на следующем монтировать.
похоже, что некоторые жесткие диски не закончат запись сектора, но файловая система ведения журнала может защитить вас от потери данных так же, как xlog защищает базу данных.
из рассылки ядра linux список в обсуждении файловой системы ведения журнала ext3:
в любом случае плохая контрольная сумма сектора аппаратная ошибка. Сектор write предполагается чтобы быть атомарным, это либо происходит, либо не.
Я бы склонен верить, что над комментарием wiki. На самом деле, само существование базы данных (firebird) без xlog подразумевает, что секторная запись атомарна, что она не может блокировать данные, которые вы не хотели изменять.
есть довольно много обсуждений здесь об атомарности сектора пишет, и опять никакого согласия. Но люди, которые не согласны, похоже, говорят о многосекторных записях (которые не являются атомарными на многих современных жестких дисках. Те, кто говорит, что сектор пишет атомно, похоже, знают больше о том, о чем они говорят.
ответ на ваш первый вопрос зависит от используемого оборудования. По крайней мере, с некоторыми старыми аппаратными средствами ответ был да-сбой питания может привести к тому, что на диск будет записан мусор. Большинство современных дисков, однако, имеют немного "UPS", встроенного в сам диск-конденсатор, который достаточно велик, чтобы питать диск достаточно долго, чтобы записать данные в кэше на диске на дисковую пластину. Они также имеют сети для того чтобы обнаружить ли электропитание все еще хорошо, поэтому когда власть становится шелушащейся, они записывают данные в кэше на блюдо и игнорируют мусор, который они могут получить.
Что касается" разорванной страницы", типичный диск принимает только команды для записи всего сектора за раз, поэтому то, что вы получите, обычно будет целым числом секторов, написанных правильно, а другие остаются неизменными. Если, однако, вы используете логический размер страницы, который больше, чем один сектор, вы можете получить страницу, которая частично написанный.
Это, однако, в основном относится к прямому подключению к обычному жесткому диску типа moving-platter. Почти со всем остальным правила могут и часто будут отличаться. Просто для очевидного примера, если вы пишете по сети,вы в основном находитесь во власти сетевого протокола. Если вы передаете данные по TCP, данные, которые не совпадают с CRC, будут отклонены, но те же данные, переданные по UDP, с тем же повреждением, могут быть общепринятый.
Я подозреваю, что это предположение неверно.
современные жесткие диски кодируют данные в секторах - и дополнительно защищают их с помощью ECC. Поэтому вы можете закончить с гарбажем всего содержимого сектора - это просто не будет иметь смысла с используемой кодировкой.
Что касается все более poplular SSDs, ситуация еще более ужасна-блок очищается до перезаписи, поэтому, в зависимости от используемой прошивки и количества свободного места, полностью несвязанные сектора может быть поврежден.
кстати, сбой ОС не приведет к повреждению данных в одном секторе.
Я ожидал бы, что одна разорванная страница будет состоять из части X, части Y и части нечитаемого сектора. Если голова находится в середине написания сектора, когда питание не работает, привод должен немедленно припарковать головы, чтобы остальная часть привода (кроме этого одного сектора) осталась неповрежденной.
в некоторых случаях я ожидал бы несколько разорванных страниц, состоящих из части X и части Y, но только одна разорванная страница будет включать нечитаемый сектор. Причина нескольких разорванных страниц в том, что диск может буферизировать множество записей внутри, а порядок записи может чередовать различные сектора с разных страниц.
Я читал противоречивые истории о том, сделает ли новая запись в нечитаемый сектор снова читаемой. Даже если ответ "да", это будут новые данные Z, ни X, ни Y.
при обновлении диск, единственный диск гарантии изготовляет делает что одиночный 512- byte write является атомарным (т. е. он либо завершится полностью, либо не будет завершите на всех); таким образом, если несвоевременная потеря мощности происходит, то только часть более крупная запись может завершиться (иногда называемая порванной записью).