about NetApp

Начнем с “классики”. Ни один наш конкурент не обходит вниманием “проблему” фрагментированности записи на том файловой системы WAFL.

Будем считать, что люди здесь собрались взрослые, поэтому я уже могу рассказать вам правду откуда берутся дети как обстоит дело с фрагментацией на WAFL на самом деле.

Вопрос: Правда ли, что запись, даже последовательных фрагментов данных, происходит на системе хранения NetApp в “рандомном” порядке, и записанная порция данных оказывается фрагментированна по пространству диска?

Ответ: Да, в общем случае это так. Это прямое следствие того, что запись на WAFL (Write Anywhere File System) происходит “Anywhere”, повсюду, где это возможно, а не в строго заданные участки, как это происходит у практически всех других файловых систем.

Зато за счет этого WAFL такая быстрая на запись. Ведь даже “рандомная” запись превращается для системы в “секвентальную”, последовательную, а это дает заметный прирост общей производительности на реальных задачах, ведь, обычно, время записи есть довольно критичный параметр в реальной жизни.
Однако следствием этого является то, что после записи данные оказываются разбросаны по дисковому пространству, что должно ухудшить результаты чтения, так, “последовательное” чтение превращается в “случайное”. Да, это все так. Но давайте углубимся в детали.

Во первых значительную часть проблемы снимает кэширование. Не секрет, что кэширование чтения есть гораздо более эффективный и “прямой” процесс. А за счет того, что данные на запись практически не задерживаются в кэше (можно считать, что кэша “на запись” как такового, такого, какой он есть у конкурирующих систем, у NetApp нет вовсе. Все записываемые данные незамедлительно уходят на диск) весь объем кэш-памяти систем NetApp это кэш чтения, и он не заполняется постоянно висящими в нем данными, ждущими очереди сброса на диск, как это происходит у “обычных^tm систем хранения”.
Все пространство памяти - это кэш чтения.

Во вторых, в системе работает процесс, осуществляющий “сборку” последовательных цепочек данных в фоновом режиме (так называемый reallocate). Таким образом, некоторое время спустя, если процессор вашей системы хранения не нагружен предельно (а такое практически не встречается, да и нежедательно), и у него есть неиспользованные “тики”, свободное время, то ваша файловая система постепенно придет в более упорядоченное, дефрагментированное состояние.

То есть, если воспользоваться аналогией наших уважаемых конкурентов, подсмотренной в документе, патетически названном “Правда о NetApp”, где сравнивается поведение “Пришел домой, покидал вещи как попало, быстро от них избавился, зато наутро ищешь носки по всему дому”, то ситуация меняется тем, что за ночь придет горничная, и покиданные как попало вещи соберет и сложит по порядку.

К сожалению, и возможно кто-то из NetApp, кто меня читает, сможет ответить почему, было принято такое решение, что процесс reallocate необходимо вручную включить, так как по умолчанию “из коробки” он остановлен. Делается это просто, командой в консоли reallocate start. Но если слабоподготовленный админ это не сделает, то, в конечном счете, он действительно может получить довольно сильно фрагментированную систему с пониженными показателями чтения.

Таким образом ответ на вопрос “существует ли проблема фрагментации на системах хранения NetApp?” довольно прост. Фрагментация - есть, а вот особых проблем, связанных с ней, как правило, - нет. Фрагментация, строго говоря, это проблема на файловых системах “каменного века”, типа FAT, но WAFL это отнюдь не FAT, поэтому переоценивать эту опасность, и уж точно считать ее “основным недостатком NetApp”, как мне порой приходится слышать - необоснованно.

Чтобы не перегружать пост я опубликую вторую часть этого поста, с ответом на вопрос: “так какова же фрагментация на WAFL в реальной жизни “в граммах” - завтра.