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

ага, особенно с включенным write-back...

вопрос: гарантируется ли в этом случае атомарность записи одного сектора ?

Нет.
Параноики обычно используют fsync()

> Параноики обычно используют fsync()

fsync() тут вообще не при чём

> гарантируется ли атомарность записи сектора накопителями?

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

Рекомендую http://www.sqlite.org/atomiccommit.html

"... SQLite does not assume that a sector write is atomic. However, it does assume that a sector write is linear. ..."

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

Журналируемые файловые системы, кажется, как-то этим управляют и заставляют его сбрасывать данные из кэша, а если просто /dev/sda открыть, кто знает что там произойдет.

fsync() тут вообще не при чём

O_o

>ага, особенно с включенным write-back...

кеш записи это уровень операционной системы, а не накопителя

>Для этого пришлось бы делать журналирование в самом накопителе, что никому не нужно.

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

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

это старая вроде как повсеместно исправленная проблема и она параллельна атомарности записи сектора

>O_o

fsync() это сброс кеша записи файловой системой, запись на уровне контроллера все равно идет секторами

> Почему бы и нет на уровне сектора?

Потому что это специфическое требование, которое мало кому нужно и которое влияет на производительность

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

Контрольная сумма используется только для обнаружения ошибок ввода/вывода. Если непосредственно во время записи сектора вырубится питание, то данные будут частично изменены, и контрольная сумма тебе ничем не поможет. У тебя окажется и новая версия недозаписанной, и старую версию тебе восстановить будет неоткуда.

>Журналирование данных на уровне файловой системы даст то, что тебе нужно.

Дело в том что я грубо говоря и разрабатываю журнал...

>Контрольная сумма используется только для обнаружения ошибок ввода/вывода. Если непосредственно во время записи сектора вырубится питание, то данные будут частично изменены, и контрольная сумма тебе ничем не поможет. У тебя окажется и новая версия недозаписанной, и старую версию тебе восстановить будет неоткуда.

И что есть случаи ошибок считывания сектора из-за неправильной контрольной суммы полученной при выключении питания накопителя???
Я о таком не слышал. Не говорит ли это в пользу того что атомарность записи сектора на уровне контроллера существует?

>И что есть случаи ошибок считывания сектора из-за неправильной контрольной суммы полученной при выключении питания накопителя???

Похоже встречаются и называются софт-бэдами, чем грешили в частности дятлы (IBM DTLA).
Выходит журнал нужно дублировать для гарантии...

> Похоже встречаются и называются софт-бэдами, чем грешили в частности дятлы (IBM DTLA).

Выходит журнал нужно дублировать для гарантии...

Так копия будет подвержена той же самой проблеме. Может лучше не писать новые блоки поверх старых? Журнал же.

>Так копия будет подвержена той же самой проблеме.

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

Может лучше не писать новые блоки поверх старых? Журнал же.

Чтобы они частично записались?

> Похоже встречаются и называются софт-бэдами, чем грешили в частности дятлы (IBM DTLA)

Я видел частично записанный сектор с некорректной CRC во время отключения питания на quantum fireball 850 Mb лет десять назад :) если с тех пор ничего не поменялось то атомарность записи не гарантируется.

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

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

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

>quantum fireball 850

А такие были? Вроде, на 850 - это Trailblazer'ы были?

Да, поскольку более низкоуровневых команд для работы с данными на HDD не имеется

> А такие были? Вроде, на 850 - это Trailblazer'ы были?

Я вспоминал-вспоминал, не помню размер, но название точно quantum fireball

Свой собственный кеш диск успевает записать всегда, даже при отклчении питания.

По моему это не так, в рассылке kernel devel в теме про барьеры писалось что если диск отрапортовал о завершении записи ещё не факт что оно попадёт на блины. Ведь если бы это было так - аппаратный sync (всякие FLUSH_CACHE FLUSH_CACHE_EXT команды у диска) бы не нужен был, достаточно было бы дождаться ответа диска о попадании данных в кеш.

>> А такие были? Вроде, на 850 - это Trailblazer'ы были?

Я вспоминал-вспоминал, не помню размер, но название точно quantum fireball

Trailblazer - это Quantun Trailblazer :) Trailblazer'ы на 850 точно были и были популярны. А вот Quantum Fireball не скажу, что с 1,3Гб начались, но популярны стали именно с 1,3Г

Свой собственный кеш диск успевает записать всегда, даже при отклчении питания.

По моему это не так, в рассылке kernel devel в теме про барьеры писалось что если диск отрапортовал о завершении записи ещё не факт что оно попадёыт на блины

Одно другому не помеха :) Винт отрапортует, что принял данные и будет писать в фоне. Но если питание отрубится, то дописать успеет. В общем, раньше это точно так было, производители гарантировали. Как сегодня - не знаю. Но отрубание по питанию USB-винта с отключенным кешем на запись к потере данных не приводит.