Да. Но это если не брать в расчет, как в конкретной ФС реализована организация хранения файлов/каталогов и их атрибутов, и к скольким таблицам придется обращаться системе (разумеется через драйвер) чтоб из уймы кластеров/блоков выбрать нужные и сгруппировать нули и единички в файл(ы)... ну или наоборот, содержимое файла записать на носитель
Вот именно в этом отношении XFS сделана гораздо более разумно:
- все каталоги - b-деревья, что ускоряет поиск файла по имени;
- списки свободных цепочек - тоже индексированы причем дважды, по расположению и по размеру - что позволяет оптимально размещать новые файлы;
- i-node, как и структуры хранения каталогов выделяются динамически - что исключает возможность иметь на диске место и не иметь возможности туда что-то записать (что случается с ext2-3-4).
- возможность асинхронного доступа сразу к нескольким частям ФС (именно для этого на XFS разделе создаются 3 - 5 allocation groups - AG).
- И только размером AG может быть ограничен непрерывный шмат диска на котором непрерывно записывается файл.
А что в EXT4?
Там свободные блоки до сих пор битовыми полями - для определения подходящего места нужно сканировать кучу битовых полей. Да только драйвер EXT2-3-4 не сильно то старается - он про фрагментацию все равно врет т.к. не может он записать без разрыва файл длинной больше чем группа блоков, т.е. 32768 блоков - ограничение вшитое в структуру начиная с EXT (та которая ext1).
Число I-node - фиксируется в момент создания и может быть только уменьшено. И если вам не приходилось то я уже сталкивался с такой петрушкой как нехватка i-node - у меня на работе админы пол дня тупили получая сообщение "нет места", когда на диске было еще дофига свободного места. Всего-то почтовый сервер всей конторы висел эти самые пол дня. - мелочь - фигня - ext4 - простительно
.
Каталоги не упорядочены. Никакого асинхронного доступа - только хардкор. И куча других анахронизмов.