Комментарии к записи: Space Reclamation http://blog.aboutnetapp.ru/archives/664 Системы хранения данных как предмет разговора Wed, 07 Apr 2021 12:07:04 +0000 http://wordpress.org/?v=2.6 Автор: Korj http://blog.aboutnetapp.ru/archives/664#comment-671 Korj Tue, 17 Aug 2010 07:09:01 +0000 http://blog.aboutnetapp.ru/?p=664#comment-671 "Система хранения об этом не знает, и не может высвободить однажды занятое таким томом место" Подождите, но ведь место-то как раз высвобождается дедупликацией! Что, кроме циферок в интерфейсе управления пострадает? Какие практические минусы, кроме "идеологически неверного" подхода? “Система хранения об этом не знает, и не может высвободить однажды занятое таким томом место”

Подождите, но ведь место-то как раз высвобождается дедупликацией! Что, кроме циферок в интерфейсе управления пострадает? Какие практические минусы, кроме “идеологически неверного” подхода?

]]> Автор: romx http://blog.aboutnetapp.ru/archives/664#comment-670 romx Tue, 17 Aug 2010 00:56:51 +0000 http://blog.aboutnetapp.ru/?p=664#comment-670 Ну так я же и написал,"что считать проблемой". Проблемой считать то, что thin provisioned LUN растут, даже если данные внутри них удаляются, и "логически" они пусты. Система хранения об этом не знает, и не может высвободить однвжды занятое таким томом место, что снижает эффекивность thin provisioning. Ну так я же и написал,”что считать проблемой”. Проблемой считать то, что thin provisioned LUN растут, даже если данные внутри них удаляются, и “логически” они пусты. Система хранения об этом не знает, и не может высвободить однвжды занятое таким томом место, что снижает эффекивность thin provisioning.

]]> Автор: Korj http://blog.aboutnetapp.ru/archives/664#comment-669 Korj Mon, 16 Aug 2010 16:02:16 +0000 http://blog.aboutnetapp.ru/?p=664#comment-669 Всё зависит от того, что считать "проблемой". Если размер LUN, и вытекающие из этого проблемы с размером volume и т.д. - то да, ухудшит. Если же место на aggr, то оно после такой операции будет свободно. Опять же, смотря что лежит на том LUN. Если на нём лежат образы дисков для виртуальных машин, то внутри у них будет та же ситуация, и во второй уровень вложенности уже только дедупликация добраться и сможет - там уже никакого snapdrive. Всё зависит от того, что считать “проблемой”. Если размер LUN, и вытекающие из этого проблемы с размером volume и т.д. - то да, ухудшит. Если же место на aggr, то оно после такой операции будет свободно.
Опять же, смотря что лежит на том LUN. Если на нём лежат образы дисков для виртуальных машин, то внутри у них будет та же ситуация, и во второй уровень вложенности уже только дедупликация добраться и сможет - там уже никакого snapdrive.

]]> Автор: romx http://blog.aboutnetapp.ru/archives/664#comment-668 romx Mon, 16 Aug 2010 09:55:53 +0000 http://blog.aboutnetapp.ru/?p=664#comment-668 Не "решит", а "ухудшит еще более". Почему - читайте внимательнее. ??, да, дедупликация никак не влияет на _размер_ LUN-а в мегабайтах. Не “решит”, а “ухудшит еще более”. Почему - читайте внимательнее.
??, да, дедупликация никак не влияет на _размер_ LUN-а в мегабайтах.

]]> Автор: Korj http://blog.aboutnetapp.ru/archives/664#comment-667 Korj Mon, 16 Aug 2010 08:35:59 +0000 http://blog.aboutnetapp.ru/?p=664#comment-667 Добавление в скедулер/крон ночью забивания нулями пустого пространства (таких утилиток пачка под любую ОС и ФС) решит проблему однозначно, как минимум при включенной дедубликации. Хотя, конечно, вместо этого шаманства честно сказать СХД об освобождённом пространстве - логичнее и быстрее. Добавление в скедулер/крон ночью забивания нулями пустого пространства (таких утилиток пачка под любую ОС и ФС) решит проблему однозначно, как минимум при включенной дедубликации. Хотя, конечно, вместо этого шаманства честно сказать СХД об освобождённом пространстве - логичнее и быстрее.

]]>