Синхронизация (Unix) - Sync (Unix)

синхронизировать это стандарт системный вызов в Unix операционная система, которая фиксирует все данные в ядро файловая система к энергонезависимый место хранения буферы, то есть данные, которые были запланированы для записи через низкоуровневый Ввод / вывод системные вызовы. Уровни ввода / вывода более высокого уровня, такие как stdio могут поддерживать собственные отдельные буферы.

Как функция в C, то синхронизация () вызов обычно объявляется как недействительная синхронизация (недействительна) в <unistd.h>. Системный вызов также доступен через командная строка утилита также называется синхронизировать, и аналогично названные функции на других языках, например Perl и Node.js (в модуле fs).

Связанный системный вызов fsync () фиксирует только буферизованные данные, относящиеся к указанному дескриптор файла.[1] fdatasync () также доступен для записи только изменений, внесенных в данные в файле, и не обязательно связанных метаданных файла.[2]

В системах Unix обычно используются какие-то румянец или же Обновить демон, который вызывает синхронизировать функционируют на регулярной основе. В некоторых системах cron демон делает это, и дальше Linux это было обработано pdflush daemon, который был заменен новой реализацией и окончательно удален из ядра Linux в 2012 году.[3] Буферы также очищаются, когда файловые системы демонтированный или перемонтировать только чтение[нужна цитата ], например, перед выключением системы.

Использование базы данных

Для обеспечения надлежащего долговечность, базы данных должны использовать какую-либо форму синхронизации, чтобы убедиться, что записанная информация попала в энергонезависимая память вместо того, чтобы просто храниться в кэше записи в памяти, который будет потерян при сбое питания. PostgreSQL например, может использовать множество различных вызовов синхронизации, включая fsync () и fdatasync (),[4] чтобы коммиты были долговечными.[5] К сожалению, для любого отдельного клиента, записывающего серию записей, вращающийся жесткий диск может фиксировать только один раз за оборот, что составляет в лучшем случае несколько сотен таких фиксаций в секунду.[6] Таким образом, отключение требования fsync может значительно улучшить производительность фиксации, но за счет возможного повреждения базы данных после сбоя.

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

Отчет об ошибках и проверка

Чтобы избежать потери данных, возвращайте значения fsync () следует проверять, потому что при выполнении операций ввода-вывода, которые буферизуются библиотекой или ядром, ошибки могут не сообщаться во время использования записывать() системный вызов или fflush () вызов, поскольку данные не могут быть записаны в энергонезависимое хранилище, а только записаны в память кеш страницы. Вместо этого об ошибках записи часто сообщают во время системных вызовов fsync (), msync () или же Закрыть().[7] До 2018 года Linux fsync () поведение при определенных обстоятельствах не смогло сообщить о статусе ошибки,[8][9] изменить поведение было предложено 23 апреля 2018 г.[10]

Споры о производительности

Жесткие диски могут по умолчанию использовать свой собственный энергозависимый кеш записи для буферизации записи, что значительно повышает производительность и создает возможность потери записи.[11] Такие инструменты как hdparm -F даст команду контроллеру жесткого диска очистить буфер кэш-памяти записи на диске. Влияние отключения кеширования на производительность настолько велико, что даже обычно консервативные FreeBSD Сообщество отклонило отключение кеширования записи по умолчанию во FreeBSD 4.3.[12]

В SCSI И в SATA с Собственная очередь команд (но не в обычном ATA, даже с TCQ) хост может указать, хочет ли он получать уведомление о завершении, когда данные попадают на пластины диска или когда они попадают в буфер диска (встроенный кеш). Предполагая правильную аппаратную реализацию, эта функция позволяет использовать встроенный кэш диска, гарантируя правильную семантику для системных вызовов, таких как fsync.[13] Эта аппаратная функция называется Принудительный доступ к юниту (FUA) и обеспечивает согласованность с меньшими накладными расходами, чем очистка всего кеша, как это делается для дисков ATA (или SATA без NCQ).[14] Хотя Linux включил NCQ примерно в 2007 году, он не включал SATA / NCQ FUA до 2012 года, ссылаясь на отсутствие поддержки в ранних дисках.[15][16]

Firefox 3.0, выпущенный в 2008 году, представил fsync системные вызовы, снижающие его производительность; вызов был введен, чтобы гарантировать целостность встроенного sqlite база данных.[17]Linux Foundation Главный инженер Теодор Ц'О утверждает, что нет необходимости «бояться fsync», и что настоящей причиной замедления Firefox 3 является чрезмерное использование fsync.[18] Однако он также признает (цитируя Майк Шейвер ), что "В некоторых довольно распространенных конфигурациях Linux, особенно при использовании ext3 файловая система в режиме «данные = упорядоченный», вызов fsync не просто сбрасывает данные для файла, который он вызвал, а скорее для всех буферизованных данных для этой файловой системы ».[19]

Смотрите также

Рекомендации

  1. ^ спецификация fsync
  2. ^ fdatasync спецификация
  3. ^ http://lwn.net/Articles/508212/
  4. ^ Вондра, Томас (2 февраля 2019 г.). «PostgreSQL против fsync». Osuosl Org. Архивировано из оригинал (mp4) 10 февраля 2019 г.. Получено 10 февраля 2019.
  5. ^ Надежность PostgreSQL и журнал предзаписи
  6. ^ Настройка синхронизации PostgreSQL WAL В архиве 2009-11-25 на Wayback Machine
  7. ^ https://lwn.net/Articles/457667/
  8. ^ https://lwn.net/Articles/752063/
  9. ^ https://lwn.net/Articles/724307/
  10. ^ https://patchwork.kernel.org/patch/10358111/
  11. ^ Запись в кэш включена?
  12. ^ Справочник FreeBSD - Настройка дисков
  13. ^ Маршалл Кирк МакКьюсик. «Диски с точки зрения файловой системы - очередь ACM». Queue.acm.org. Получено 2014-01-11.
  14. ^ Грегори Смит (2010). PostgreSQL 9.0: высокая производительность. Packt Publishing Ltd. стр. 78. ISBN  978-1-84951-031-8.
  15. ^ http://www.spinics.net/lists/linux-scsi/msg61241.html
  16. ^ http://lkml.indiana.edu/hypermail/linux/kernel/0702.2/1358.html
  17. ^ http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
  18. ^ http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
  19. ^ http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/

внешняя ссылка