и написали для таких как вы - что это _ramdisk_. Даже не nvme - ram! У тебя скорость доступа к оперативной памяти зависит от того, последовательно или случайно ты ее читаешь?
(зависит, на самом-то деле, но это не про "фрагментацию")дальше - можно ковыряться в их тесте и искать, как, собственно, они добились таких уникальных результатов, особенно занятна разница между write и read (потому что должна была проиграть ext4, а мы видим обратное).
А можно плюнуть и забыть - потому что к реальному применению это все имеет околонулевое отношение. Это, скорее всего - вполне хороший тест - для узкоспециальной задачи автора - сравнить голую производительность fs отдельно от аппаратуры, чтобы доказать, что его код нужно включить в ведро, а тот что есть - отправить на свалку.
А если хочется добиться понимания, влияет ли фрагментация на производительность современных прямоугльных "дисков" и как - нужно делать совсем-совсем другой тест, и, главное - разбираться в его результатах и искать причины, а не мантры про "фрагментацию" бормотать.
тест, скорее всего, будет банален - открываем 500 файлов одновременно, и начинаем туда писать по 64k - последовательно в каждый, дергая flush каждый раз - и так по гигабайтику.
Дальше ищем инструменты (где-нибудь на винде, полагаю) - если они покажут, что ядро или кто там не смогло нас обмануть и файлы записаны в виде замысловато переплетенной вермишели (как оно, по идее и должно получиться, если драйвер не устроит какую-нибудь "оптимизацию" - но это придется именно проверять. Возможно придется close/open вместо flush делать)
Потом просто замеряем cat * > /dev/null - и сравниваем с таким же и из той же пачки диском, куда те же 500 записаны последовательно целиком. Если результаты не равны - ищем причину. Она НЕ в "фрагментации", она - в постановке эксперимента. Чудес - не бывает. Мыши из грязного белья не самозарождаются.
