Исходное сообщение
"Обновление ZFSonLinux 0.6.2, реализации ZFS для ядра Linux " Отправлено Аноним, 26-Авг-13 14:41
> Не торопитесь говорить гоп. Вот одна из историй "успеха": >>Сервер мы собрали, Нексенту поставили. Поставили нам ее официальные партнеры Нексенты, сертифицированные инженеры. >>первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. … на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков: максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =) >>Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером. >>Еще про дедупликацию на блочном уровне. Это не работает, забудьте. >>Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее. > http://habrahabr.ru/company/hostkey/blog/179151/ > и это на нексенте. вот на линухе http://habrahabr.ru/post/153461/ А башкой поработать вообще - слабо? С какого перепугу система с идеологией CoW должна при таком заполнении сохранять производительность? И - насколько это лютый недостаток в условиях МАССОВОГО производства терабайтных винтов?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Не торопитесь говорить гоп. Вот одна из историй "успеха": >>>Сервер мы собрали, Нексенту поставили. Поставили нам ее официальные партнеры Нексенты, сертифицированные инженеры. >>>первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. … на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков: максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =) >>>Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером. >>>Еще про дедупликацию на блочном уровне. Это не работает, забудьте. >>>Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее. >> http://habrahabr.ru/company/hostkey/blog/179151/ >> и это на нексенте. вот на линухе http://habrahabr.ru/post/153461/ > А башкой поработать вообще - слабо? С какого перепугу система с идеологией > CoW должна при таком заполнении сохранять производительность? И - насколько это > лютый недостаток в условиях МАССОВОГО производства терабайтных винтов?
	Введите код, изображенный на картинке: