Является ли дисковый сектор атомарным?

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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

См:

Ответ 4

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

Из wikipedia (http://en.wikipedia.org/wiki/Journaling_file_system):

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Кстати, авария ОС не приведет к повреждению данных в одном секторе.

Ответ 7

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

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

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

Ответ 8

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