Влияние различных размеров блока VMFS

На одном из форумов VMTN написали о неожиданном влиянии единого размера блока для всех томов VMFS. Пользователь произвел обнуление неиспользуемого пространства, чтобы диски скомпрессировались при Storage vMotion. Сюрпризом стало то, что диски остались того-же самого размера и после Storage vMotion.

После нескольких тестов было обнаружено, что при Storage vMotion между массивами, или между датасторами с различными размерами блока VMFS диски компрессировались. Почему?
Ответ прост: в этом случае используется другой datamover (модуль перемещения данных). Поскольку вам это мало о чем говорит, объясню какие бывают datamover'ы:

• fsdm - самый старый datamover, с минимумом функций и самый медленный, поскольку данные проходят по всему стеку.
• fs3dm - был включен в состав vSphere 4.0 и содержал некоторые значительные изменения, позволяющие данным проходить не все уровни стека.
• fs3dm – hardware offload – datamover с поддержкой VAAI, аппаратной интеграции операций ввода/вывода с массивом. Появился в vSphere 4.1, имеет максимальную производительность и минимальные накладные расходы.

Так в чем же проблема? А проблема в одной маленькой строке текста в VAAI FAQ:

• The source and destination VMFS volumes have different block sizes

Как только выбирается датастор с другим размером блока, или датастор на другом массиве - гипервизор переключается на fsdm. Одно из немногих преимуществ этого datamover'а в том, что он "съедает" нули. В то время как fs3dm, вне зависимости от software / hardware offload, этого не делает и копирует блоки целиком.

Источник: Duncan Epping (yellow-bricks.com)