Занялся оптимизацией моей тормозоZFS

rsync -avh --progress American\ Gangster.mkv  American\ Gangster.mkv_ 
sending incremental file list
American Gangster.mkv
       5.88G 100%   40.15MB/s    0:02:19 (xfer#1, to-check=0/1)

sent 5.88G bytes  received 31 bytes  41.84M bytes/sec
total size is 5.88G  speedup is 1.00

SSD (забитыйн а 80%+), ext4

Не, я все понял, ты чоткий пацан, но у меня не SSD, а мы меряем ФС

HDD у меня нету :(

а мы меряем ФС

Как бы харды все разную скорость чтения записи имеют.

Вот только у меня 5МБ/с пока-что

Внутри пула zfs:

     779.68M  30%   16.39MB/s    0:01:43  

С одного пула на другой:

     682.92M  27%   30.70MB/s    0:00:58  

Ах да, оба пула поверх разных dm_crypt на разных дисках :)
Кроме того, жадный я на ARC.

от 21 до 31 MB/s
reiserfs notail,noatime

может она у тебя уфрагментированная вусмерть?

ZFS же эльфы делали, ей такое не грозит, она магические все делает идеально.

Если серьезно то я случайно заметил что у меня 150 ГБ сжато

sent 2.45G bytes received 31 bytes 28.36M bytes/sec

ext4, Seagate ST3000DM001

А ничо что тебе щас перемеряют HDD в разных областях? В начале диска скорость раза в 2 больше, чем в конце.

не в 2 раза
а вообще - разница между 5 и 20+ далеко не в 2 раза, оха!?

Я имел в виду линейную скорость обмена данными с контроллером. Если учесть все жизненно-бытовые нюансы, можно и больше разницу получить.

линейная...60% не больше

ssd, zfs

sent 3.15G bytes  received 31 bytes  53.82M bytes/sec

Мда. Это в переделах одного пула:

sent 4.29G bytes  received 31 bytes  42.69M bytes/sec

А это на разных, на разных девайсах:

sent 4.29G bytes  received 31 bytes  77.30M bytes/sec

Девайсы - два рэйда на SAS.

Для сравнения, вот оно же на ext4, на одном девайсе:

sent 12.50G bytes  received 31 bytes  107.32M bytes/sec

На разных девайсах:

sent 12.50G bytes  received 31 bytes  196.89M bytes/sec

Железо идентичное.

Так что да, тяжеловат ZFS пока.

Как-то оптимизировал zfs?

Практически никак. Ограничил ARC-кэш двумя гигами и увеличил kern.maxvnodes и vm.kmem_size_max. Остальное - чисто на дури рэйда и дисков. Плюс всякие atime отключил, но на одном файле оно не влияет ни на что.

А если ARC-кэш не ограничивать, какая скорость будет?

В пределах одного пула:

sent 12.50G bytes  received 31 bytes  42.17M bytes/sec

Между двумя пулами:

sent 12.50G bytes  received 31 bytes  67.40M bytes/sec

Сервера сейчас стоят без нагрузки, так что это близко к пределу.

Сервера перед самым тестированием перезагружали хотя бы?

ext4, ~25MB/s

Сервера перед самым тестированием перезагружали хотя бы?

А что, уже придумали способ задавать ограничения ARC-кэша не через loader.conf?

Да, если есть возможность, хотелось бы таки помериться скоростями. Если честно, ZFS для меня до сих пор практически тёмный лес. Даже после чтения того переведённого мануала по её архитектуре, который в 2008 написан.

Потому что уйти от ZFS возможности нет, а ускорить её таки хотелось бы.

sent 1.90G bytes  received 31 bytes  41.65M bytes/sec

ZoL 0.6.1. mirror на WDC WD30EFRX и ST3000DM001, заполнен на 20%. zpool v28. SATA-III. Гонял внутри пула. Не гербалайф.

Потому что уйти от ZFS возможности нет, а ускорить её таки хотелось бы.

Есть три пути: 1) расширить пул новыми девайсамиl; 2) увеличить количество девайсов внутри зеркального пула; 3) перевести пул на SSD. Выбирай.

А что, уже придумали способ задавать ограничения ARC-кэша не через loader.conf?

Так вроде ж там sysctl-переменные, которые можно менять на лету, или нет?

Мне бы интенсивный путь, экстенсивным пока не получится. Ну а раз нет - что ж, очень жаль.

Так вроде ж там sysctl-переменные, которые можно менять на лету, или нет?

Это не те переменные, которые можно менять на лету.

Это не те переменные, которые можно менять на лету.

в оригинале можно дебагером mdb на лету поменять, может и в линуксе аналогично.
а скорость и в правду неприличная. что за рейды на sas? hw raid с nvram?
это прочитано?
зы можно ssd использовать в качестве l2arc и zil туда же.

Мне бы интенсивный путь

zfs set checksum=off poolname/poolfs

не советую больше такого, вдруг кто-то так и сделает.

Вот интересно стало, другие ФС проверяют?

в оригинале можно дебагером mdb на лету поменять

Аппендицит тоже можно себе самостоятельно вырезать. Только лучше не надо.

что за рейды на sas?

LSI с батарейкой, 10 и 1. Плюс кэш-девайс на SSD на самом контроллере. Но он только на чтение работает.

За ссылку спасибо, поизучаю. L2ARC в такой конфигурации уже мало что может поправить.

Да, ось таки фряха, 9.1-STABLE, ядро из svn от 19 июня.

zfs set checksum=off poolname/poolfs

Не, спасибо. Только после написания fsck_zfs.

для других ФС есть fsck

Проверит ли fsck если 10 станет 15? Просто отключение контрольных сумм в ZFS считается очень плохой идеей почему-то даже для домашних машин. Тем не менее я не уверен что какие-то контрольные суммы считаются другими ФС. У них скорее всего надежда что диски будут вести себя хорошо или просто исправление посредством RAID

в оригинале можно дебагером mdb на лету поменять

Аппендицит тоже можно себе самостоятельно вырезать. Только лучше не надо.

ох уж эти аналогии. стесняюсь спросить, с чего бы это? нормально всё меняется.

LSI с батарейкой

попробуй отключи cache flush опцией 'zfs:zfs_nocacheflush=1' и прогони тест ещё раз, если будет разница, то смотри на lsi на предмет игнора сброса кэша.
только обратно не забудь включить, если есть пулы на девайсах без батареек.

нормально всё меняется.

ось таки фряха, 9.1-STABLE, ядро из svn от 19 июня.

У меня нет mdb, увы.

попробуй отключи cache flush опцией 'zfs:zfs_nocacheflush=1'

Не в курсе, как оно на фряхе делается? Если что, 'vfs.zfs.cache_flush_disable=1' сейчас.

Да, а какие у вас скорости на ZFS? И на каком оборудовании?

Тем не менее я не уверен что какие-то контрольные суммы считаются другими ФС. У них скорее всего надежда что диски будут вести себя хорошо или просто исправление посредством RAID

В этом-то и дело!

Сранивать Ext4 с ZFS, у которой включены контрольные суммы, не совсем корректно. Нужно опустить ZFS до уровня обыной ФС, чтобы получить сравнимые результаты тестов.

Сранивать Ext4 с ZFS, у которой включены контрольные суммы, не совсем корректно.

Оно, может, и не совсем корректно с точки зрения сравнения технологий, но с точки зрения использования у ZFS, увы, нет другого способа как-либо гарантировать целостность ФС. Поэтому сравнивать приходится с тем, что есть.

Да, сбои с неработоспособностью ZFS мне встречались, увы. Даже с чексуммами.

Тоесть если отключить чексуммы у ZFS, то она станет более ненадежной чем reiserfs/ext4 у которых в помине нет чексум (может и есть, поправьте меня если что)?

Тоесть если отключить чексуммы у ZFS, то она станет более ненадежной чем reiserfs/ext4

Да. Потому что для неё отсутствует fsck, которым можно было бы что-то починить в случае сбоя.

А scrubbing?

У меня нет mdb, увы.

что, у фри тоже нет приличных дебагеров? )

Если что, 'vfs.zfs.cache_flush_disable=1' сейчас.

это похоже оно и есть.

Да, а какие у вас скорости на ZFS? И на каком оборудовании?

sent 4.33G bytes  received 31 bytes  84.02M bytes/sec

это на внутренних дисках сервера производства 2006 года, где сидят ещё человек 15-20 одновременно и делают работу с интернетиками и прочим, solaris11.

а вообще посмотрел dtrace что там этот rsync делает и стала не понятна суть тестировать копирование одного файла при помощи сокетов и писать 4kb блоками, у zfs по-умолчанию 128kb, если что.

писать 4kb блоками, у zfs по-умолчанию 128kb, если что

Ну так кеш сработает, чо

И неясно зачем сокеты при локальном режиме работы rsync

писать 4kb блоками, у zfs по-умолчанию 128kb, если что.

Мда. Этого я не учёл. Проверил, dd с мегабайтным размером блоков выдал скорость 250Мб/с, а на 128кб блоках - 160Мб/с.

В самом деле, тест не релевантный получился.

Вырубил чексуммы, начала летать. До этого комп грузился 6 мин