Intereting Posts
sshfs mount – файлы / папка создаются как root без учета параметров uid / gid Как узнать, является ли раздел ext2, ext3 или ext4? Ноутбук падает на видеодрайвер Vesa Как обнаружить и предупредить, если процесс использует 100% процессор в течение длительного времени? Перемещение папок с определенным ключевым словом в имени в новую папку Что произойдет, когда мы подключим устройство к компьютеру Измените приглашение PS1 в подэлементе sh, вызванном из родительского bash Считается ли синтаксис подстановки команд $ () оператором или командой? Такое же меню grub для двух дистрибутивов GNU / Linux Дружественный ресурс для указания программы пользователя не висит Команда Sed запускается с жестко заданным значением в регулярном выражении, но с ошибкой с переменной в сценарии Понимание командной строки Bash's Read-a-File Изменение владельца папки в SCO Найти и для цикла nvidia-smi висит бесконечно: что может быть проблемой?

Какие файловые системы требуют fsync () для защиты от сбоев при замене существующего файла на rename ()?

После распространенных жалоб ext4 получила гарантию безопасности при auto_da_alloc называемую auto_da_alloc которая включена по умолчанию. А как насчет других файловых систем? Какие из них предоставляют такую ​​же гарантию (а какие нет) из наиболее известных файловых систем?

Лично мне интересно услышать информацию о

  • XFS – стандартная файловая система Red Hat Enterprise Linux.
  • btrfs – файловая система SuSE Enterprise по умолчанию.
  • bcachefs – исходная файловая система Linux, производная от bcache. «Файловая система COW для Linux, которая не пожирает ваши данные».

Эта проблема в основном касается Linux, согласно истории ниже. Было бы интересно узнать, как ZFS ведет себя так же, но я склонен полагать, что это не будет реализовано.

Что такое auto_da_alloc ?

fsync () хорошо документирован как правильный способ записи данных файла, например, когда вы нажимаете «сохранить» в текстовом редакторе. И общепризнанно, что, например, текстовые редакторы должны заменять существующие файлы атомарно, используя rename (). Это предназначено для защиты от потери питания, гарантируя, что вы всегда сохраняете старый файл или получаете новый файл (который был переименован fsync () перед переименованием). Вы не хотите, чтобы вас оставили только наполовину написанную версию нового файла.

Но была проблема в том, что вызов fsync () для ext3, которая была самой популярной файловой системой Linux, могла эффективно заставить всю систему зависать на десятки секунд. Поскольку приложения ничего не могут с этим поделать, было очень распространено оптимистично использовать rename () без fsync (). Этот шаблон, казалось, работал довольно хорошо в этой файловой системе, даже если система потеряла питание.

Следовательно, существуют приложения, которые неправильно используют fsync ().

Следующая версия файловой системы ext4, как правило, избегала зависания функции fsync (). В то же время он стал больше полагаться на правильное использование fsync ().

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

Это было решено в ext4, чтобы поддержка шаблона rename () без использования функции fsync () для обеспечения безопасности при сбоях обеспечить поведение при сбое, как это делала старая файловая система ext3. Это поведение может быть отключено снова, если вы монтируете с опцией noauto_da_alloc .

    В этом вопросе есть ошибка. Вопрос подразумевал, что этот сценарий сделан полностью безопасным от auto_da_alloc . Это не верно для ext4. Я полагаю, что это было не так в старом ext3. Однако это верно для btrfs и для bcachefs.

    В последних версиях ext4 есть специальный обходной путь, позволяющий снизить вероятность замены с помощью переименования при создании файлов нулевой длины путем принудительного вытеснения новых блоков данных при переименовании. Однако переименование не дожидается завершения этого сброса и, следовательно, не дает никакой гарантии атомарности – после сбоя можно получить только частичное новое содержимое. Из протестированных нами файловых систем btrfs является единственной, которая обеспечивает гарантию атомарности замены через переименование.

    https://homes.cs.washington.edu/~lijl/papers/ferrite-asplos16.pdf


    btrfs документации btrfs говорится, что rename () в btrfs обеспечивает полную атомарность и не требует явного fsync () для защиты данных от сбоев. Я думаю, что это было добавлено примерно в то же время, что и ext4 auto_da_alloc . Мы также видим утверждение, что реализация btrfs позволяет избежать снижения производительности, так как это не заставляет ждать вызов rename ().

    bcachefs настоящее время bcachefs обеспечивает полный уровень защиты, хотя я не нашел никакой документации. Проверьте код по адресу https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/fs.c?id=fb0522fd844a#n726.

    XFS отклонил добавление обходных путей безопасности для rename (). Очевидно, он получил код, который снижает (но не устраняет) риск потери данных в другом случае.

    UBIFS (используется, например, на многих устройствах Openwrt) не содержит каких-либо обходных путей безопасности для rename (). Это может быть принято, но потребует много работы. http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions