> Тормознутость ZFS тогда пролечилась несколькими командами отключающими свойство
> дедупликации у всех ФС этого пула. 1) Не понимаю как дедупликация может влиять на скорость чтения. Ну запись еще понятно, но у тебя ж вроде и чтение было в такой же лузе? Чтобы осознать насколько это луза: ARMовская платка с гигагерцевым процом и гигом оперативы с EXT4 читает с одного ноутбучного диска 90Мб/сек. Ну правда диск терабайтник и 7200RPM (да, такое нынче в 2.5" упаковывают).
> Почему ты это старательно замалчиваешь, я не возьму в толк.
Не помню чтобы ты показывал новые данные.
> Другая опа случилась при апгрейде ZFS пулов после обновления системы: просто они
> были заполнены на 99% и не хватило места для новых метаданных
Ну ты напрасно так с CoW - он тебе выносков нагородит и файлы по мере дозаписи/перезаписи превратятся в вермишель, равномерно размазанную по всему диску, на механике это будет означать отвратную скорость последовательного чтения. При том у ZFS дефрагера IIRC вообще совсем нет и undo этого безобразия можно сделать только стерев большинство файлов в надежде что свободное место придет в менее вермишельный вид. Только для эффективности этого деяния надо почти все файлы снести, что по смыслу близко к пересозданию пула с ноля.
> - ФС перешли в состояние read only. Но, опять же, и
> эта проблема решилась удалением некритичных файлов.
Да проблема CoW не в том, а в выносках с отличиями от предыдущего варианта. Если с местом душняк - даже обычная ФС будет распихивать файлы не "как лучше" а "как получится", постепенно превращаясь в мелкую вермишель. А CoW из-за своей природы количество фрагментов будет плодить еще быстрее. Саночники судя по их FAQам явно в курсе проблемы, раз советуют добавлять диск в пул при занятости в 80%. Что забавнее - они кажется не имеют плана действий на случай если это все-таки случилось. А в долговременном плане количество фрагментов все-таки будет увеличиваться и скорость работы ФС может деградировать.
