UBIFS: Неожиданное поведение (выравнивание износа)

Question

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

• Записывает файл со случайными данными в файловую систему, расположенную на томе ubi
• Проверяет содержимое файла
• Удаляет файл

Этот тест проводится определенное количество раз (около 200 000). «Подчеркнутый» том UBI был смонтирован на другом томе UBI. Как и ожидалось, максимальное количество стираний для «напряженного» объема уби увеличилось. Что я также заметил, так это то, что максимальное количество стираний для объема UBI места монтирования также увеличилось. Я бы не ожидал этого.

1. Кто-нибудь знает, что может вызвать это? Что-то в UBI? Или какой-то механизм в ядре Linux (например, ведение журнала)?

2. Кто-нибудь видел такой тип поведения с другими файловыми системами, которые реализуют выравнивание износа?

Answer 1

Два процесса в системе взаимодействуют через Unix Domain Socket . Этот сокет создается в томе UBI «монтирования» (я не знаю, в каком месте он находится). Когда я переместил этот файл в расположение в оперативной памяти (т. Е. / Tmp), запись на том UBI для монтирования прекратилась. Во время стресс-теста розетка существовала, но не использовалась. Было бы хорошо узнать, почему файловая система считает, что необходимо записывать файл после каждой синхронизации.

Answer 2

Первое предположение может заключаться в том, что ведение журнала времени доступа включено, или , может быть, время модификации, если тесты выполняются в корне «нагруженного» тома. Скорее всего, время доступа - смонтировать внешнюю файловую систему (на самом деле, вероятно, обе) с -noatime.