Возможно, запись на hdd будет произведена автоматикой hdd при отключении питания.

Мимопроходил

Если говорить вообще: гарантий нет.

http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html:

fsync() might or might not actually cause data to be written where it is safe from a power failure

Если в частности, в линукс-мане такое написано:

The fsync() implementations in older kernels and lesser used filesystems does not know how to flush disk caches. In these cases disk caches need to be disabled using hdparm(8) or sdparm(8) to guarantee safe operation.

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

запись на hdd будет произведена автоматикой hdd при отключении питания.

Причём иногда — в случайные места диска.

Мимопроходил

А что, дискам хватает энергии записывать что-то? Я думал только головку припарковать.

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

Причём иногда — в случайные места диска.

вот да! Наткнулся на такой момент, что после выдергивания кабеля из компа почему-то перестал быть исполняемым бинарь, а после его удаления, из тех объектников из которых он собирался - слинковать не удалось, пришлось их пересобирать. Что за нафиг вообще.

Видимо только то что в буферах было? А их объем еще знать надо? Если в случайные - какой в этом смысл? Или места случайные, но ОС корректно потом этим данные читает как будто не случилось ничего - тогда понятно.

Были сообщение на эту тему в каком-то древнем обсуждении журналирования ФС. Жёсткие диски при потере питания сходили с ума и до остановки успевали что-то там напортить. Из-за различия в расположении метаданных некоторые ФС хорошо переживали отключения питания, а другие от этого ломались. В частности, этим объяснялись обнуления файлов на старых версиях XFS при восстановлении — лучше потерять файл целиком, чем остаться с возможно испорченным.

Если в случайные - какой в этом смысл?

Смысла нет, это баг железа.

Btrfs как обычно... (комментарий)

всё ещё не нашёл ссылки на оригинал, только вот тут: http://linuxmafia.com/faq/Filesystems/reiserfs.html

Кинетическая энергия пластин.

Так пластины же достаточно быстро замедляются, если с них ещё и энергию вращения снимать. Неужели электроника диска умеет адекватно позиционироваться в таких условиях? Возможно, я нуб (точнее, я наверняка нуб), но сброс кэшей на останавливающийся диск звучит уж очень как sci-fi.

intelfx См. ответ i-rinat: fsync (комментарий)

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

Это могло иметь место раньше, но никак не сейчас. Сейчас brown-out-детекторы в каждую перемычку лепят.

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

Да, я понимаю. Если там под это дело отведены зарезервированные дорожки, да ещё и не одна, тогда, возможно, это и работает...

Да это понятно. Гарантии, что что-нибудь запишется вообще нет.

Кинетическая энергия пластин.

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

пеши исчо

Не уверен что надежность fsync должна волновать в вопросе реальной надежности сохранения данных. Ок, представь что fsync абсолютно надежно гарантирует запись на диск. И диск ломается в следующую секунду.

Для реальной надежности нужны несколько мест хранения с разным failure domain. Failure domain - что-то общее у двух систем, которое может сломаться одновременно. Примеры failure domain: один жесткий диск, одна машина, один источник питания, одно подключение к сети, один датацентр, одна ОС, одна страна, один континент, одна планета. Failure в каждом из них имеет разную вероятность проявиться. Например у одной планеты - очень низок. Ты должен выбирать насколько далеко ты готов пойти ради надежности.

Если у тебя надежность системы зависит от fsync - поздравляю, у тебя приличный список высоковероятносных failure domain совпадают одновременно.

На практике для надежности хватает распределенной ФС с репликацией. В одном датацентре надежность ниже, в нескольких - выше.

Не уверен что надежность fsync должна волновать в вопросе реальной надежности сохранения данных
На практике для надежности хватает распределенной ФС с репликацией

Думаю стоит расписать задачу конкретнее.

Есть некий набор данных, размером в 1кб. Он хранит состояние системы(конфиги). Необходимо сделать так, что чтобы эти конфиги сохранялись в процессе работы.

Для хранения конфигов есть два файла. Софт поочередно пишет в них последнее состояние конфигов. Задача в том, что перед очередной записью необходимо как-то убедиться, что прошлая запись завершена (физически)

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

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

поочередно

Поочередно в смысле в оба? Или поочередно в смысле длина журнала конфигов равна 2. Обычно все такое пишут вместо config в config.31231231312 (timestamp), закрывают файл, что делает fsync само и потом меняют симлинку из config на новую версию.

Иногда журнал подтирают

offtop конечно, но меня всегда удивляло почему не делали резервирование прямо в БП. По идее 1 акк. 12В*7Ач хватит чтобы отключить видео, сбросить все кеши, и уйти в hibernate. Схемотехника БП не сильно усложнится, а простые АКБ очень дёшевы.

Мне кажется тогда бы не получилось продавать батарейки для рейдов каждый год по 2к баксов каждая.

закрывают файл, что делает fsync само

Тут закралось заблуждение.

Use ИБП, Luke! АКБ деградируют со временем, не уверен что многие хотели бы иметь это в компе, а потом в нужный момент понять что они уже не держали. Вот в HDD/SDD я бы встроил большой кондёр, чтобы дописывал хотя бы что в кэше.

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

Таки да, ты прав

https://www.sqlite.org/howtocorrupt.html grep fsync

# dd bs=1m count=1k if=/dev/random of=bigfile.1
# md5 bigfile.1 
MD5 (bigfile.1) = 30624a8e2c03508443aeddd36e4a27e6
# cp bigfile.1 bigfile.2 ; reboot -qn
# md5 bigfile.1 bigfile.2
MD5 (bigfile.1) = 30624a8e2c03508443aeddd36e4a27e6
MD5 (bigfile.2) = 30624a8e2c03508443aeddd36e4a27e6
#

То ли sync успевает, то ли -qn не так работает как написано в мануале.

И в очередной раз благодарствую за советы и ответы по данному вопросу. Только вернулся от заказчика и раньше ответить не мог.

В общем fsync() похоже решил таки мою задачу.

В треде было много годных советов и копипаст, в случае, если будут ошибки - будет пища для размышлений, но теоретически все ок)

Тред пусть будет закрытым, всем большое спасибо!

закрывают файл, что делает fsync само

man fclose

NOTES
       Note  that  fclose() only flushes the user-space buffers provided by the C library.  To ensure that the data is physically stored
       on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).

частности, этим объяснялись обнуления файлов на старых версиях XFS

На внешних USB-HDD + ntfs или стационарных HDD + ext4 такое наблюдалось (обнуление)? А то у меня таким образом потерялось довольно много файлов на трёх HDDs.

https://www.sqlite.org/howtocorrupt.html grep fsync

cx.commit() автоматически выполняет fsync?

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

Лично я долгое время не пользовался XFS, поэтому ни разу не замечал. Ext4 и reiserfs пользовался долго, но там тоже не замечал.