Операция чтения в файловой системе

У меня очень тупой вопрос. Когда выполняется операция чтения, я тоже делаю запись? Я думаю о записи в области журнала, потому что мои метаданные изменены, как время Mac. Мое мышление не так? Я хочу сделать вывод, что барьер записи, включенный в моей файловой системе ext4, не может существенно повлиять на производительность операций чтения.

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

В зависимости от рабочей нагрузки вы, тем не менее, можете повысить производительность своих операций ввода-вывода, используя либо параметр noatimeмонтирования, либо relatimeтот, который используется по умолчанию в современных ядрах.

По умолчанию Linux использует параметр монтирования "relaytime" для всех файловых систем, который обновляет поле atime, только если оно устарело более чем на 24 часа, или если atime <mtime (поскольку некоторые программы чтения почты используют это, чтобы определить, является ли три непрочитанных письма в / var / mail / XXXX файл). Это значительно уменьшает количество записей метаданных. Существует также опция монтирования noatime, которая полностью отключает запись. Поля relaytime и noatime технически нарушают соответствие POSIX, хотя в наши дни большинство людей не заботятся о строгом соответствии POSIX.

В Linux 4.2 и более новых ядрах также есть опция монтирования «lazytime», которая обновляет все поля полей меток времени в памяти (так что это всегда точно) во время работы системы. Временные метки на диске обновляются (а) когда файловая система отключена, (б) если временные метки устарели более чем на 24 часа, (в) если нужно обновить какое-либо другое поле инода в этом иноде - например, i_size , i_blocks, i_mode, i_uid и т. д. ---- или (d) (только оптимизация для ext4), существует соседний индекс в том же блоке таблицы индексов, который обновляется на диске.

Таким образом, преимущество lazytime заключается в том, что вы получаете обратно соответствие POSIX, и оно также подавляет обновления mtime для нераспределенных случайных записей в файл (например, в случае файла табличного пространства базы данных предприятия, такого как то, что Oracle или DB2 могут использовать ). Тем не менее, в lazytime возможно не иметь одно значение временной метки во время работы системы, и в случае сбоя (в отличие от чистого размонтирования файловой системы) вы получите другое значение временной метки после перезагрузки. Это допускается POSIX, который дает гарантии согласованности только после fsync (2) или umount (2), но возможно, это может удивить некоторые приложения.