С полным журналированием данных, почему данные сразу появляются в каталоге?

Во-первых, Вы правы подозревать, что “все данные” не означают целый файл. На самом деле тот слой файловой системы воздействует на блоки файла фиксированного размера, не на целые файлы. На том уровне важно сохранить ограниченный объем данных, таким образом работая над целыми файлами (который может быть произволен большой), не работал бы.

Во-вторых, в Вашем вопросе существует неправильное представление. Поведение журналирования не что-то, что можно наблюдать путем рассмотрения содержания каталога с ls, это работает на намного более низком уровне. С нормальными инструментами Вы будете всегда видеть, что файл там. (Это было бы катастрофически, если создание файла, казалось, не, y'know, создало его.), Что происходит под капотом, то, что файл может храниться по-разному. Сначала, первые несколько блоков сохраняются в журнале. Затем как только эффективно возможно, данные перемещены в его заключительное местоположение. Это - все еще тот же файл в том же каталоге, просто сохраненном по-другому.

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

Для получения дополнительной информации о журналах файловой системы, я рекомендую запуститься со статьи Wikipedia. В терминах ext3, a data=journal гарантирует, что, если система отказывает, каждый файл находится в состоянии, которое это имело в какой-то момент перед катастрофическим отказом (это - не всегда последнее состояние из-за буферизации). Причина этого не происходит автоматически, состоит в том, что ядро переупорядочивает записи на диск для эффективности (это может иметь большое значение). Это называют “физическим журналом” в статье Wikipedia. Другие два режима (data=ordered и data=writeback) формы “логического журнала”: они быстрее, но они могут привести к поврежденным файлам. Журнал ограничивает риск повреждения в несколько файлов, содержащих мусор; ext3 всегда использует полный журнал для метаданных. Без журнала для метаданных метаданные могут потеряться, ведя к основному повреждению файловой системы. Кроме того, без журнала, восстановление после того, как катастрофический отказ требует полной проверки целостности файловой системы, тогда как с журналом восстановление означает воспроизводить несколько записей журнала.

Обратите внимание, что даже с журналом, типичные файловые системы Unix не гарантируют глобальной непротиворечивости файловой системы, только непротиворечивость на файл самое большее. Таким образом, предположите, что Вы пишете в файл foo, затем Вы пишете в файл bar, затем системные катастрофические отказы. Это возможно для bar иметь новое содержание, но foo все еще иметь старое содержание. Чтобы иметь полную непротиворечивость, Вам нужна транзакционная файловая система.

Я предполагал, что если я что-то скачаю, сначала следует сохранить в журнале , а после завершения переместить в FS.

Вы имеете в виду, что файл должен появляться только после закрытия. Это похоже на необязательное поведение Ext4, см. параметр монтирования , называемый auto_da_alloc .

auto_da_alloc | noauto_da_alloc

Многие неработающие приложения не используют fsync (), когда noauto_da_alloc заменяет существующие файлы с помощью таких шаблонов, как

fd = open ("foo.new") / write (fd , ..) / close (fd) / rename ("foo.new", "foo")

или еще хуже

fd = open ("foo", O_TRUNC) / write (fd, ..) / закрыть (fd).

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