> Если разница тестирования дисковых операций с двумя различными фс будет отличаться по
> времени на 1-2% то это уложится в погрешность измерений.

А она будет местами отличаться не на 1-2% а в пару раз. А то и поболее. Просто потому что в силу разного дизайна ФС, разным дизайнам удобны разные наборы операций.

> Следовательно для тестирования больше подходят быстрые SSD диски нежели HDD.

Неверно. ФС претендующая на универсальность должна уметь работать и с теми и с другими. Хотя это не значит что там не может быть специальных оптимизаций для тех или иных носителей. На практике современный подход как раз сигналить ФС о том что это у нас SSD и тогда она юзает иной набор оптимизаций + TRIM. Вроде бы логично все. Разным по свойствам носителям - разные оптимизации и твики.

> во всех тестируемых ос. Например многие "пРоФФэсоры" высказываются неодобрительно о том
> же dd, зато он есть почти везде. Итак если мы говорим
> о dd какие bc и count будут оптимальны для тестирования ?

В моем понимании, если мы хотим потестировать ФС а не крутизну кеша - размер данных должен быть заведомо много больше кэша, чтобы посмотреть что может ФС. Что может кэш я и так себе представляю. Вот только в него вся ФС не влезет (иначе это уже RAM-диск) и потому интересно и поведение ФС самой по себе. Как бы bs и count будут варьироваться в зависимости от доступной под кэш памяти. Более того, bs в принципе может влиять на производительность дисковой подсистемы. Обычно крупные блоки отрабатываются лучше чем мелкие (до некоторого предела). Способность работать с неудобными сценариями когда программы читают/пишут мелкими блоками - тоже параметр ФС. А кто сказал что программы всегда оперируют большими блоками? Например логи дописываются мелкими порциями.

Но это только 1 из тестов. Самый простой и дубовый - на линейные операции в 1 поток.

А как насчет интенсивной работы с метаданными? Время создания разлапистой структуры каталогов и файлов - это тоже интересный параметр. Когда распаковываается нечто типа тарбола с ядром производительность ФС в таких случаях сыграет не последнюю роль.

А как насчет многопоточного доступа? Современные ОС многозадачные и доступ сразу кучи программ к диску ничему не противоречит. Насколько ОС, ее кеш и ФС смогут облегчить участь диска, особенно механического?

Некоторые программы могут запросить небуферизованный "прямой доступ". В этом случае кэш не имеет права подыгрывать. Скорость работы ФС в таком режиме - тоже интересна. Просто потому что некая программа может лучше чем ОС и системный кэш знать что и как кешировать.

Есть тесты нагружающие логику журналирования - синхронизируемая запись. Т.е. записи файлов сдабриваемые вызовами типа fsync(). Актуально для БД и прочих. Реализация оного может влиять на скорость работы БД. Кстати если кто хочет подъ... btrfs - вот тут это может получиться.