LINUX.ORG.RU

fsync

 


0

2

Команда fsync проталкивает kernel space данные на жесткий диск.

Вопрос, если непосредственно после вызова fsync выключить питание компьютера, то могут ли данные застрять в кэше самого HDD или данная функция гарантирует их проталкивание в том числе и через кэш HDD? Или это как-то зависит от модели HDD?

Вопрос может и нубский и может строка мана должна ответить на мой вопрос

This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed.

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


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

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

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.

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

SysVinit-hater ()
Ответ на: комментарий от mittorn

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от mittorn

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

Burns ()
Ответ на: комментарий от i-rinat

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

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

Burns ()
Ответ на: комментарий от i-rinat

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

I-Love-Microsoft ★★★★★ ()
Ответ на: Мимопроходил от SysVinit-hater

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

i-rinat ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от mix_mix

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от SysVinit-hater

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

intelfx ★★★★★ ()
Ответ на: комментарий от mix_mix

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

intelfx ★★★★★ ()
Ответ на: комментарий от Burns

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

mittorn ★★★★★ ()
Ответ на: комментарий от mix_mix

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

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

пеши исчо

anonymous ()

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

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

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

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

vertexua ★★★★★ ()
Ответ на: комментарий от vertexua

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

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

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

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

Burns ()

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

Iron_Bug ★★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Burns

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

Iron_Bug ★★★★★ ()
Ответ на: комментарий от Burns

поочередно

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

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

vertexua ★★★★★ ()

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

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

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

anonymous ()
Ответ на: комментарий от MKuznetsov

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

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

I-Love-Microsoft ★★★★★ ()
# 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 не так работает как написано в мануале.

anonymous ()

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

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

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

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

Burns ()
Ответ на: комментарий от vertexua

закрывают файл, что делает 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).

Burns ()
Ответ на: комментарий от i-rinat

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

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

pacify ★★★★★ ()
Ответ на: комментарий от pacify

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

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

i-rinat ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.