ZFSonLinux 0.6.4 вышел!

так они с zvol её используют, я писал, что без обвеса ненужна.

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

ну я думаю ты согласишься, что без zvol, zfs принципе и не нужна.

Не соглашусь.

Если ты про размещение корня на ZFS - ты прав

Причем здесь корень? Или ты хочешь сказать, что memory-mapped i/o только для отображения сегментов либ в адресное пространство процесса используется? Тогда у меня для тебя плохие новости. Было врeмя, когда memory-mapped i/o давало преимущества в скорости в сравнении с обычным read/write, и было очень популярно прикручивать его везде где ни попадя, так что помимо системы и куча приложений может его испольовать в хвост и в гриву. Так что читать эти ваши интернеты - оно, конечно, полезно, но иногда и голову включать тоже.

Однако, если ты больше знаешь об организации кэша, не затруднит тебя пояснить, почему кэш ZFS отображается как ЗАНЯТАЯ память в Linux(а не как дисковой кэш собственно), что приводит к очень веселым последствиям, если на сервере кроме хранения данных нужно что-то еще требовательное к RAM?

Ну это же элементарно, Ватсон! Достаточно посмотреть, что делают zio_buf_alloc()/zio_data_buf_alloc() и вопрос должен отпасть сам собой.

Получилось у меня в онлайн провести замену диска, и расширение. :)

Получилось у меня в онлайн провести замену диска, и расширение. :)

Нашел чему радоваться! Было бы странно, если бы не получилось.

Достаточно посмотреть, что делают zio_buf_alloc()/zio_data_buf_alloc() и вопрос должен отпасть сам собой.

Для тех, кто понимает в потрохах ядра - да. Я же честно признаюсь, что исходники ядра и модулей к нему для меня - китайская грамота.

Получилось у меня в онлайн провести замену диска, и расширение. :)

У меня не было ни малейших сомнений, что именно так и будет. Проблема ушла?

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

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

Пока в логах тишина. :) Так что да... Вполне возможно ушла. Но вывод то каков..? Вывод такой, что: (по-крайней мере) zfs, при сбое чтения с диска, начинает чудить, и фризиться, вместо того, чтобы выкинуть сразу из массива сбойный диск. Хотя, у меня сбоило, одновременно, два диска. Ну в общем, как-то так, надо ещё всё же просматривать dmesg иногда.

это был риторический вопрос

у zfs нет механизма взаимодействия с дисковым тлер, отключать тлер.

Каких только чудес не увидишь в этих ваших линуксах, был неправ. Тогда, для полноты картины, что ещё за ограничения?

Что, прямо так сразу по аватаре видно?

у zfs нет механизма взаимодействия с дисковым тлер, отключать тлер.

У zfs и не должно быть такого механизма, выбрасывать сбойный диск должен контроллер, а zfs просто фиксирует факт, что диск пропал, и тлер тут в помощь как раз, не будет длительных попыток прочитать сбойный сектор.

выбрасывать сбойный диск должен контроллер

каким образом? zfs хочет прямой доступ к диску в режиме jbod, в этом случае контролер все еще может вмешаться в работу и дать понять zfs что диск мертв? просто проводил опыты - втыкал диски (без тлер) с бедблоками в массив zfs, все работало как и работало, без фризов, диски контроллером не выбрасывались, как и когда zfs должен послать на покой говнодиск для меня загадка. А окончание дисковых транзакций zfs может ждать сколь угодно долго, поэтому и думаю что источником непонятных фризов является именно дисковый tler.

вот тут NiTr0 поясняет:

если аппаратный рэйд - TLER нужен, если рэйд из JBOD на аппаратном контроллере - могут быть варианты, в зависимости от драйвера/контроллера, в прочих случаях (контроллер как HBA или набортный AHCI/ATA контроллер) - на TLER глубоко пофиг.

сцылка - hdd WD caviar blue для raid1 (комментарий)

Весьма похоже на правду...

каким образом? zfs хочет прямой доступ к диску в режиме jbod, в этом случае контролер все еще может вмешаться в работу и дать понять zfs что диск мертв?

На мой взгляд - нет, не может вмешаться, ровном счётом, никак.

В теории - может. Если контроллер решит что диск умер и отсох, и прекратит любые попытки пообщаться с ним. На практике - может и есть такие контроллеры, но из тех пары что побывали у меня в руках - таких не было.

Ты как сбойные SSD, у себя находил? Кто у тебя их выкидвыал? Контроллер в режиме JBOD, или zfs?

сбойные SSD

а как определить что ssd сбоит, т.е. как бы работает, но уже имеет проблемы?

Короче SSD падал в режим readonly и zpool status -v показывал degraded массив. Никаких зависонов не было.

Либо на нём все данные разом пропадают, либо он в ro падает.

Если приложение использует mmap, то можно оставить кэш только под метаданные. Но это касается и линукса, так что не легенда, а скорее реальность с исключением.

Если приложение использует mmap, то можно оставить кэш только под метаданные.

Можно-то оно можно, вот только стоит ли? Можно, конечно, использовать блоки размером 4K, чтобы избавиться от необходимости читать блок ФС при записи страницы, но это резко увеличит количество метаданных. В противном случае для записи страницы придется сначала прочитать с диска блок, в который она попадает (ведь в кэше его нет), потом скопировать в него содержимое страницы, и записать новый блок в новое место с новой котрольной суммой, индиректами и т.д., а потом немедленно выкинуть этот новый блок из кэша.

Вобщем может получиться по Черномырдину - хотели как лучше, а получилось как всегда.

Плюс это вызовет голод для L2ARC, если он используется, ведь L2ARC кормится с хвоста списка блоков в кэше.

Можно, конечно, использовать блоки размером 4K

Наверное, зависит от паттерна, но можно ведь поднять размер страницы, у некоторых клиентов такой финт работает.