Возможно ли реализовать ведение журнала с помощью одного fsync на коммит?

Question

Допустим, вы создаете систему хранения журналирования / записи с опережением записи.Вы можете просто реализовать это путем (для каждой транзакции) добавления данных (с помощью write (2)), добавления маркера фиксации и последующего fsync-ing?

Сценарий, который следует рассмотреть, если вы делаете большой наборof пишет в этот журнал, затем fsync его, и во время fsync произошел сбой .Прямые / косвенные указатели блоков inode сбрасываются только после того, как сброшены все блоки данных, или нет никаких гарантий, что блоки очищаются по порядку?Если последнее, то во время восстановления, если вы видите маркер фиксации в конце файла, вы не можете поверить, что данные между ним и маркером предыдущего фиксации имеют смысл.Таким образом, вы должны полагаться на другой механизм (включающий, по крайней мере, другой fsync), чтобы определить, какой размер файла журнала является согласованным (например, запись / fsyncing данных, затем запись / fsyncing маркера фиксации).это имеет значение, главным образом задаваясь вопросом о ext3 / ext4 в качестве контекста.

Answer 1

Обратите внимание, что fuxync и fdatasync в linux и mac os по умолчанию некорректны. Windows верна по умолчанию, но может эмулировать linux для целей тестирования.

Кроме того, fdatasync выдает несколько операций записи на диск, если вы добавляете в конец файла, так как ему необходимо обновить inode файла с новой длиной. Если вы хотите иметь одну запись для каждого коммита, лучше всего заранее выделить место в журнале, сохранить CRC записей журнала в маркере фиксации и выполнить одну функцию fdatasync () при фиксации. Таким образом, независимо от того, сколько ОС / аппаратного упорядочения за вашей спиной, вы можете найти префикс журнала, который фактически ударил по диску.

Если вы хотите использовать журнал для длительных фиксаций или писать вперед, все становится сложнее, поскольку вам нужно убедиться, что fsync действительно работает. В Linux вы захотите отключить кэш записи диска с помощью hdparm или смонтировать раздел с установленным в true барьером. [Редактировать: Я исправлен, барьер, кажется, не дает правильную семантику. SATA и SCSI вводят ряд примитивов, таких как барьеры записи и собственные очереди команд, которые позволяют операционным системам экспортировать примитивы, которые позволяют вести запись с опережением записи. Судя по тому, что я могу узнать из man-страниц и онлайн, Linux предоставляет их только разработчикам файловых систем, а не пользователям.]

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

Наконец, реальные системы используют групповую фиксацию и выполняют <1 синхронную запись на коммит с одновременными рабочими нагрузками. </p>

Answer 2

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

Если вы хотите принудительно упорядочить, вам нужно как минимум fdatasync() между записями, которые вы хотите заказать. Все обещания синхронизации состоят в том, что , когда он возвращает , все, что написано до того, как синхронизация достигнет хранилища.