Скажите пожалуйста, а еще статьи по этой теме будут? А то у меня есть пара небольших дополнений, хотел бы вынести их в отдельный топик, «по следам» вашей серии, так сказать.
А если серьезно, я буду повторять слова Дрю Блисса каждый раз, когда патчу Wine под WorldOfTanks, потому что на дефолтном у меня FPS в три раза ниже. Глядишь, нервы целее будут ))
Если Steam для Linux выстрелит (а что у Valve не выстрелило?), то будет круто. Видеодрайверы, даже проприетарные, под Linux намного хуже, чем под Window. Например, __GL_THREADED_OPTIMIZATIONS появилась только в последней бете Nvidia, и пока только уменьшает FPS, а не увеличивает. А под Windows тот же WOW уже давным-давно в два потока GPU исполняется, даже патч какой-то был для Wine, который обеспечивал такое и в Linux. Драйвера от AMD точно не лучше. Свободные драйвера для 3D-игр практически не подходят.
У Valve есть возможность пинать производителей драйверов, чтобы те сокращали отставание Linux-драйверов от Windows с одной стороны, и выпускать новый версии своего движка, в которых есть пути обхода конкретных проблем драйвером, с другой стороны. Как-то же они сделали, чтобы L4D под Linux шустрее бегало, чем под Windows?
Для решения описанных проблем в Dell Compellent используется программное обеспечение Dynamic Capacity™, которое полностью отделяет выделение ресурсов от их использования. Сама функция получила название Thin Provisioning.
Красиво написано, но функция выделения данных по требованию получила название Thin Provisioning раньше, чем придумали Fluid Data. :)
Может ли Dynamic Capacity (tm) освобождать на хранилище место, ранее занятое файлами. а потом — освобожденное?
Если да, то какие ОС поддерживаются? ОС же должна сообщить хранилищу, что больше не использует какие-то блоки через драйвер хранилища (команды TRIM и WRITE SAME не все ОС поддерживают)
Каков алгоритм перераспределения данных между хранилищами? Учитывает ли он, что к некоторым данным возможны обращения, у примеру, строго один раз в месяц с максимальной скоростью, а в промежутках их никто не трогает?
Сколько стоит хранение терабайта данных в вашей системе?
Использовал ее для той же задачи — файл сервер с некритичными данными. Сама ФС, как я понимаю, сверхстабильна, и в случае чего, можно снять диски, закинуть их на сервер с OpenIndiana и починиться. Но вот реализация конкретно для Linux не то чтобы рановата для продакшена, но должна использоваться с оговорками. Вот об оговорках я и написал ).
Надеюсь, через год можно будет внедрять в ответственных проектах. А вот когда допилять btrfs — вопрос. ZFS, по крайне мере, стабильно работает на Solaris, а btrfs стабильно пока нигде не работает.
Ну, я поставил ZFS ради одной вещи — L2ARC. Эта штука позволяет подключать SSD-диск в качестве кэша к дисковому тому. Правда кэширование — только на чтение. Под Linux тоже есть что-то в этом духе, но не мейнлайн-ядре и с непонятной поддержкой.
Дедупликация — это, конечно, модно, но экономит только место, а не IOPS. Дедупликация хороша для виртуальных сред, но все равно проигрывает thin provisioning средствами гипервизора или блочного устройства (например, Device Mapper-а в Linux).
Компрессия тоже экономит место, и немного — IOPS, но размер экономии сильно зависит от самих данных.
А если серьезно, я буду повторять слова Дрю Блисса каждый раз, когда патчу Wine под WorldOfTanks, потому что на дефолтном у меня FPS в три раза ниже. Глядишь, нервы целее будут ))
Если Steam для Linux выстрелит (а что у Valve не выстрелило?), то будет круто. Видеодрайверы, даже проприетарные, под Linux намного хуже, чем под Window. Например, __GL_THREADED_OPTIMIZATIONS появилась только в последней бете Nvidia, и пока только уменьшает FPS, а не увеличивает. А под Windows тот же WOW уже давным-давно в два потока GPU исполняется, даже патч какой-то был для Wine, который обеспечивал такое и в Linux. Драйвера от AMD точно не лучше. Свободные драйвера для 3D-игр практически не подходят.
У Valve есть возможность пинать производителей драйверов, чтобы те сокращали отставание Linux-драйверов от Windows с одной стороны, и выпускать новый версии своего движка, в которых есть пути обхода конкретных проблем драйвером, с другой стороны. Как-то же они сделали, чтобы L4D под Linux шустрее бегало, чем под Windows?
места под данные, конечно
Красиво написано, но функция выделения данных по требованию получила название Thin Provisioning раньше, чем придумали Fluid Data. :)
Надеюсь, через год можно будет внедрять в ответственных проектах. А вот когда допилять btrfs — вопрос. ZFS, по крайне мере, стабильно работает на Solaris, а btrfs стабильно пока нигде не работает.
Дедупликация — это, конечно, модно, но экономит только место, а не IOPS. Дедупликация хороша для виртуальных сред, но все равно проигрывает thin provisioning средствами гипервизора или блочного устройства (например, Device Mapper-а в Linux).
Компрессия тоже экономит место, и немного — IOPS, но размер экономии сильно зависит от самих данных.
Так что какая ФС лучше, надо смотреть «по месту».