LINUX.ORG.RU

История изменений

Исправление vitalif, (текущая версия) :

Добрался-таки, потестил немного... Главный, конечно, вопрос - это ЧЕМ всё-таки тестить файловую систему.

Потому что тесты типа sysbench --test=fileio и iozone - это фигня, они не ФС тестируют, а по сути производительность диска. Что и подтверждают результаты - идентичные в рамках погрешности у ext4 и XFS при случайном смешанном чтении/записи блоками по 16кб (наверное, кстати, типичное для СУБД использование). Причём как в мелких файлах, так и в крупных - видимо, потому, что он их сначала ВСЕ открывает, а потом читает/пишет. Ясно же, что это криво - чтобы ФС тестить, надо создать огромную кучу файлов в папках, а в момент обращения файл открывать, читать, закрывать... А в идеале - вообще какую-нибудь смешанную нагрузку, типа там чтение/создание/запись/удаление...

Хотя то, что они на случайном доступе идентичны - тоже результат, значит, по крайней мере, ни одна из них НЕ ПОРТИТ производительность нижележащего девайса.

Сделал только два вменяемых теста: во-первых, таки да, копирование исходников ядра (с SSD с прогретым кэшем, т.е. в чтение не упирающееся) - в один и в четыре потока (в 4 потока = 4 копии исходников). В 1 поток на ext4 занимает 7.7 сек, на xfs - 12.3 сек. 4 потока на ext4 заняли 33.9 сек, а на xfs - 65.9 сек.

Во-вторых, fs_mark, записывающий 1 мб файлы в разное число потоков. На нём ext4 был лучше, причём лучше масштабировался. https://yourcmc.ru/wiki/Ext4_vs_XFS

Теперь бы ещё найти что-нибудь, чем можно было потестить случайное чтение и/или смешанную нагрузку на большом дереве файлов...

Однако между делом найдено преимущество XFS над ext4 - в XFS inode'ы выделяются динамически, то есть они, с одной стороны, не могут кончиться, с другой - не расходуют лишнее место на диске. А в ext4 место под иноды фиксировано и НЕ МЕНЯЕТСЯ после создания файловой системы - сменить можно, только пересоздав её. По умолчанию на каждые 4 4кб-блока выделяется 1 256-байтный инод, откуда путём нехитрых вычислений следует, что 1/64 ёмкости диска тратится «впустую». Ну, не впустую... а под иноды. Особенно это заметно на всяких крупных разделах с фильмами - места впустую расходуется дофига, если количество инодов не подкручивать... На всяких /usr и /home с кучами исходников ещё ладно, но и там у меня по 70-80% инодов свободно при 80-90% занятом пространстве.

Ну то есть по дефолту у xfs есть небольшая заморочка - он старается делать, чтобы номера блоков с инодами влезали в 32 бита (типа обратная совместимость), и поэтому изначально старается, насколько это возможно, зарезервировать им начало диска (первые 25%). Но если сказать mount -o inode64 - этой заморочки нет и вообще всё нормально.

Исправление vitalif, :

Добрался-таки, потестил немного... Главный, конечно, вопрос - это ЧЕМ всё-таки тестить файловую систему.

Потому что тесты типа sysbench --test=fileio и iozone - это фигня, они не ФС тестируют, а по сути производительность диска. Что и подтверждают результаты - идентичные в рамках погрешности у ext4 и XFS при случайном смешанном чтении/записи блоками по 16кб (наверное, кстати, типичное для СУБД использование). Причём как в мелких файлах, так и в крупных - видимо, потому, что он их сначала ВСЕ открывает, а потом читает/пишет. Ясно же, что это криво - чтобы ФС тестить, надо создать огромную кучу файлов в папках, а в момент обращения файл открывать, читать, закрывать... А в идеале - вообще какую-нибудь смешанную нагрузку, типа там чтение/создание/запись/удаление...

Хотя то, что они на случайном доступе идентичны - тоже результат, значит, по крайней мере, ни одна из них НЕ ПОРТИТ производительность нижележащего девайса.

Сделал только два вменяемых теста: во-первых, таки да, копирование исходников ядра (с SSD с прогретым кэшем, т.е. в чтение не упирающееся) - в один и в четыре потока (в 4 потока = 4 копии исходников). В 1 поток на ext4 занимает 7.7 сек, на xfs - 12.3 сек. 4 потока на ext4 заняли 33.9 сек, а на xfs - 65.9 сек.

Во-вторых, fs_mark, записывающий 1 мб файлы в разное число потоков. На нём ext4 был лучше, причём лучше масштабировался. https://yourcmc.ru/wiki/Ext4_vs_XFS

Теперь бы ещё найти что-нибудь, чем можно было потестить случайное чтение и/или смешанную нагрузку на большом дереве файлов...

Однако между делом найдено преимущество XFS над ext4 - в XFS inode'ы выделяются динамически, то есть они, с одной стороны, не могут кончиться, с другой - не расходуют лишнее место на диске. А в ext4 место под иноды фиксировано и НЕ МЕНЯЕТСЯ после создания файловой системы - сменить можно, только пересоздав её. По умолчанию на каждые 4 4кб-блока выделяется 1 256-байтный инод, откуда путём нехитрых вычислений следует, что 1/64 ёмкости диска тратится «впустую». Ну, не впустую... а под иноды. Особенно это заметно на всяких крупных разделах с фильмами - места впустую расходуется дофига... На всяких /usr и /home с кучами исходников ещё ладно, но и там у меня по 70-80% инодов свободно при 80-90% занятом пространстве.

Ну то есть по дефолту у xfs есть небольшая заморочка - он старается делать, чтобы номера блоков с инодами влезали в 32 бита (типа обратная совместимость), и поэтому изначально старается, насколько это возможно, зарезервировать им начало диска (первые 25%). Но если сказать mount -o inode64 - этой заморочки нет и вообще всё нормально.

Исходная версия vitalif, :

Добрался-таки, потестил немного... Главный, конечно, вопрос - это ЧЕМ всё-таки тестить файловую систему.

Потому что тесты типа sysbench --test=fileio и iozone - это фигня, они не ФС тестируют, а по сути производительность диска. Что и подтверждают результаты - идентичные в рамках погрешности у ext4 и XFS при случайном смешанном чтении/записи блоками по 16кб (наверное, кстати, типичное для СУБД использование). Причём как в мелких файлах, так и в крупных - видимо, потому, что он их сначала ВСЕ открывает, а потом читает/пишет. Ясно же, что это криво - чтобы ФС тестить, надо создать огромную кучу файлов в папках, а в момент обращения файл открывать, читать, закрывать... А в идеале - вообще какую-нибудь смешанную нагрузку, типа там чтение/создание/запись/удаление...

Сделал только два вменяемых теста: во-первых, таки да, копирование исходников ядра (с SSD с прогретым кэшем, т.е. в чтение не упирающееся) - в один и в четыре потока (в 4 потока = 4 копии исходников). В 1 поток на ext4 занимает 7.7 сек, на xfs - 12.3 сек. 4 потока на ext4 заняли 33.9 сек, а на xfs - 65.9 сек.

Во-вторых, fs_mark, записывающий 1 мб файлы в разное число потоков. На нём ext4 был лучше, причём лучше масштабировался. https://yourcmc.ru/wiki/Ext4_vs_XFS

Теперь бы ещё найти что-нибудь, чем можно было потестить случайное чтение и/или смешанную нагрузку на большом дереве файлов...

Однако между делом найдено преимущество XFS над ext4 - в XFS inode'ы выделяются динамически, то есть они, с одной стороны, не могут кончиться, с другой - не расходуют лишнее место на диске. А в ext4 место под иноды фиксировано и НЕ МЕНЯЕТСЯ после создания файловой системы - сменить можно, только пересоздав её. По умолчанию на каждые 4 4кб-блока выделяется 1 256-байтный инод, откуда путём нехитрых вычислений следует, что 1/64 ёмкости диска тратится «впустую». Ну, не впустую... а под иноды. Особенно это заметно на всяких крупных разделах с фильмами - места впустую расходуется дофига... На всяких /usr и /home с кучами исходников ещё ладно, но и там у меня по 70-80% инодов свободно при 80-90% занятом пространстве.

Ну то есть по дефолту у xfs есть небольшая заморочка - он старается делать, чтобы номера блоков с инодами влезали в 32 бита (типа обратная совместимость), и поэтому изначально старается, насколько это возможно, зарезервировать им начало диска (первые 25%). Но если сказать mount -o inode64 - этой заморочки нет и вообще всё нормально.