Полностью по замыслу. Когда вы делаете узел с диском Inconsistent
первичным, он, по сути, читает и записывает по сети одноранговый узел с диском UpToDate
.
Если бы вы разорвали сетевое соединение, когда Inconsistent
диск был основным, все бы очень быстро пошло наперекосяк. ;-)
То же самое относится и к сбою диска на основном узле. DRBD переключится на бездисковый режим, а затем отправит все операции чтения и записи на одноранговый узел (, предполагая, что у однорангового узла есть диск с номером UpToDate
. Это может помочь избежать отключения службы из-за сбоя локального диска.
Это первое, что я прочитал с info sync
, которое приводит меня к разделу «Синхронизация операций ввода-вывода» (arch linux ).
In most modern operating systems, the normal I/O operations are not executed synchronously. I.e., even if a 'write' system call returns, this does not mean the data is actually written to the media, e.g., the disk.
С помощью man 3 sync
я получаю "Руководство программиста POSIX" :Функция sync()должна...расписание... . А потом:
The writing, although scheduled, is not necessarily complete upon return from sync().
Я вижу две ситуации, когда это имеет значение:
программисты :Если вы делаете низкоуровневое чтение сразу после записи (что-то в этом роде)
пользователи :Если отсоединить (внешний )блок -устройство сразу после записи. Если не размонтировать, может помочь синхронизация. Но если вы все равно umount
(и должны ), вам не нужна синхронизация.
Я полагаю, на практике имеет значение, если вы выполняете одно dd
с небольшими блоками для быстрого внутреннего устройства в бездействующей системе (пользователь не может побеспокоить это )или если несколько dd
процессы записывают огромные блоки в разные разделы медленного USB.
Даже с синхронизацией (man 1 sync):
BUGS Persistence guarantees vary per system. See the system calls below for more details.
Вопрос:
So when writing to a block device, are the any circumstances in which dd will exit before all writing has completely finished? Has this actually ever happened to anyone?
Ну да, если индикаторы мигают, это означает, что флэш-памяти USB все еще требуется питание для хранения этих блоков. И к тому времени, когда вы закончите набирать «синхронизация», все будет готово.
Пришло время ответить на этот вопрос.
В течение столь долгого времени я думал, что кешируются только записи в файловые системы, а не блочные устройства, только чтобы обнаружить, что я ошибался:записи в блочные устройства кэшируются .
Строго говоря, у меня нет официального источника по этому вопросу, и я буду обновлять свой ответ по мере его получения , но вы можете найти некоторую информацию здесь:linux -Block кеш устройства против файловая система -Unix & Linux Stack Exchange. Извините, я только что заметил, что вы тоже видели этот вопрос!
На самом деле, у меня возникла проблема: записать образ на USB-накопитель, извлечь его после завершения и обнаружить, что он поврежден. Это не должно было вести себя так, поскольку кажется, что полная синхронизация выполняется на последнем close()
на устройстве, поэтому я предполагаю, что либо у меня есть повреждение данных на моем устройстве,или я пропустил процесс, в котором все еще было открыто блочное устройство, но в любом случае я больше не рискую.
Так что да, добавление параметров синхронизации в dd
при записи на блочное устройство не похоже на городскую легенду. Я думаю, что conv=fdatasync
должно быть достаточно и лучше всего (метаданные файла не добавляются в конце концов, и действительно необходима только синхронизация в конце процесса ), но экстремисты среди нас могут предпочестьoflag=sync
(полные данные + синхронизация метаданных после каждой записи ). Проверьте man 2 open
и man 2 fdatasync
для получения дополнительной информации.
Согласно тому, что я читал (, но на данный момент нет ничего официального, к сожалению, ), cp
и cat
для блочного устройства действительно могут выйти до синхронизации, если какой-то другой процесс все еще имеет блочное устройство. open, если только явно не запрошено с некоторыми флагами SYNC, когда устройство open()
ed или с помощью системного вызова синхронизации, такого как fdatasync()
, fsync()
или более преувеличенно sync()
, чего не делает ни одна из этих команд...