about NetApp

Так что же там на самом деле происходит с фрагментацией на NetApp?

Давайте, для начала, разберемся с основами. Я в этом блоге уже не раз писал о проблеме фрагментации, и желающих сошлю в более ранние посты, например сюда и сюда.

К сожалению тема фрагментации данных на WAFL до сих пор остается в некотором роде эзотерическим знанием. Связано это, в первую очередь с тем, как мне представляется, что рассказ о фрагментации и необходимом противодействии ему, затрагивает ряд чувствительных особенностей функционирования WAFL, деталях, которые NetApp, по разным причинам (совсем не обязательно злонамеренным), разглашать пока не хочет.

Поэтому официальная позиция состоит в рекомендации, в случае, если влияние фрагментации в вашем конкретном случае, проявляется негативно (она, кстати, может и не проявляться), то включать wafl reallocate ( reallocate on / reallocate start [/vol/volname]) и спать счастливо.

Вообще же FUD вокруг non-contiguous wafl blocks allocation построен (впрочем, как и почти любой FUD) вокруг плохого представления технических деталей процесса и иногда чистосердечного, а чаще злонамеренного “непонимания” этих деталей. Давайте, для начала, разберем как же записываются данные в WAFL, по крайней мере на том уровне, на котором нам этот процесс показывает NetApp.

Но начать придется издалека.

Как вы знаете, сама аббревиатура WAFL расшифровывается как Write Anywhere File Layout, то есть “Файловая структура с записью повсюду”. Тут, не вдаваясь в подробности, источник FUD-а говорит: “Раз запись повсюду, а мы знаем, что адресуемый блок данных на WAFL это 4KB, значит структура WAFL представляет собой мешанину из 4KB-блоков, записанных вперемешку, налицо ужасная фрагментация, ведущая, как мы все знаем со времен трехдюймовых флопиков на FAT12, к сильному падению производительности на чтении!”

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

WAFL изначально находится в родстве с родоначальником всех UNIX-like файловых систем – Berkeley’s FFS. ??значально, давным давно, когда Windows имела еще номер версии 3.1,  Data ONTAP, в самых первых своих версиях, использовала часть кода BSD4.2, и многие тогдашние решения естественным образом перекочевали в исходный релиз Data ONTAP. Несмотря на то, что WAFL это отдельная, “своя собственная” файловая система, некоторые идеи FFS она, тем не менее, использовала (“мы все стоим на плечах гигантов” говорил кто-то из великих).

Во-первых это модель организации записей в виде дерева inodes. Тут WAFL во многом родственна всем многочисленным потомкам FFS, существующим на разнообразных свободных и коммерческих юниксах, фактически, до совсем недавнего времени, большинство практических файловых систем UNIX так или иначе перелицовывали (для большей “скорострельности”, в основном) идеи оригинальной FFS. Подробнее об организации дерева inodes в WAFL можно почитать в оригинальной работе Хитца и Лау, на которую я тут уже не раз ссылался. Вот – оригинал, вот – перевод.

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

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

Если же у файловой системы не находится последовательной цепочки нужной длины, то тогда она начинает искать две последовательных цепочки половинной длины, пусть и в разных местах, и так далее. В результате, блок данных, который мог бы быть, в идеальном случае, записан целиком в одну такую цепочку последовательных блоков, оказывается разбит на две и более цепочки таких последовательных блоков (прошу обратить внимание, что внутри этой цепочки блоки все равно будут последовательны!). ?? так до тех пор, пока, в отдаленном наихудшем случае, у нас не находится на диске ни одного протяженного цельного куска последовательных блоков, и вся цепочка запишется в n-блоков, где каждый блок равен размеру единственному адресуемому дисковому блоку.
К слову сказать, точно такой же метод выделения свободного пространства и записи его реализован, например в NTFS.

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

??ным путем шли файловые системы семейства FAT, идущие от еще более древних файловых систем OS CP/M. Эти файловые системы изначально проектировались под использование на флоппи-дисках (для не заставших этот продукт моих молодых читателей расскажу, что это были гибкие пластиковые диски в конверте с прорезью, емкостью сперва 80 и 160 килобайт, затем 360 килобайт, потом появились маленькие дискетки на 3.5” в жестком пластиковом корпусе, производства Sony, емкостью 1,4 мегабайта. Вы наверняка можете посмотреть на последних представителей этого вымирающего вида магнитных носителей в вашей бухгалтерии). Очевидно, что для носителя емкостью всего 80-160 килобайт, на счету был каждый байт, поэтому в файловой системе FAT запись делалась в первый же найденный свободный блок, затем в следующий свободный блок, и так далее, совершенно без связи с расположением предыдущих. Это позволяло максимально экономично использовать пространство флоппи-диска, ну а что до быстродействия, то флопики и так, сам по себе, не были особенно быстродействующими, и об этом, при создании FS, не особенно думали.

Все изменилось, когда произошел рывок в области магнитных носителей, и жесткие диски стали стремительно увеличиваться в емкости. Но на тот момент исторически на персональных компьютерах закрепились OS семейства DOS и ранние Windows, являвшихся просто расширением возможностей DOS, а они все пришли с совсем небольших “персоналок”, где иногда даже и жесткого-то диска не было.

Отсюда файловые системы семейства FAT стихийно распространились на жестких дисках, на носителях, на которых, повторюсь, использовать их не планировалось изначально, и на которых механизмы FAT работали плохо. Но все же работали. Если на 160-килобайтном флопике все тормозило и без проблем с производительностью на уровне FS, то после перехода на значительно более быстродействующие жесткие диски, стали проявляться “родовые проблемы” несовершенной и неприспособленной для этого типа носителей файловой системы.

Одной из наиболее значительных стала фрагментация данных на жестких дисках. Как вы видите из описания алгоритма записи FAT, он вообще не заморачивался минимизацией фрагментов, и, как следствие, с ходом жизни файловой системы, когда на ней создаются и удаляются файлы, когда количество их растет, а удаляются они произвольно, то есть возникаю разбросанные по диску “дыры” свободного места, растет и фрагментация, то есть ситуация, когда содержимое файла оказывается лежащим не последовательно, а разбросанным по поверхности диска, записанное в свободные на тот момент блоки. Появившиеся вскоре программы “дефрагментации”, которые просто алгоритмически реализовывали оптимизацию процесса записи, по сути то же самое, что делает FFS непосредственно на этапе записи: находя достаточный пустой фрагмент, считывая записанный “вразброс” диск, собирая его в памяти, и записывая его туда целиком, в виде последовательной цепочки блоков, значительно улучшили ситуацию с размещением данных на дисках c FAT.

Радикальное улучшение производительности тогдашних DOS и Windows, на тот момент довольно “условно многозадачных”, работающих поверх FAT, достигаемое таким простым и дешевым способом, привело к передающемуся из поколения в поколение преданию о страшности фрагментации на диске и чудодейственности дефрагментации. Многие люди начали выполнять процедуру дефрагментации просто как ежедневный (или ежекакполучится) “обряд”, не вдаваясь в его технические детали и фактическую нужность. К тому же, отдадим должное программистам Нортона, дефрагментация очень эффектно и наглядно изображала, что компьютер РАБОТАЕТ. :) Моргала лампочка, стрекотали головки, а по экрану двигались квадратики. :) Со времен крутящихся бобин магнитной ленты на мэйнфреймах не было такой красивой визуализации процессов “работы компьютера”.

Однако вспомните, что я рассказывал о алгоритме выделения места в FFS, и вы поймете, отчего среди unix-people так долго существовало убеждение, что “на UNIX секса нет фрагментации нет”. Долгое время также считалось и про NTFS, под Windows NT . Это считалось само собой разумеющимся настолько, что, например, программы дефрагментации под NTFS появились значительно позже выхода собственно NT, а, например, на ext2/ext3, наиболее распространенных FS под Linux, их, фактически, нет до сих пор (если не брать всякие загадочные утилиты, делающие какую-то загадочную “уличную магию”, с неясным результатом), что не мешает этим файловым системам широко и успешно использоваться многие годы.

Шло время, и несколько лет спустя, сперва Microsoft, а затем и некоторые unix-people согласились с тем, что фрагментация на их файловых системах все же есть. ?? что с ней неплохо бы что-то делать. Ну просто для порядка.
Она есть, однако это не совсем та же фрагментация, что на FAT.
Принято считать, что, хотя на “потомках FFS” и NTFS ситуация с непоследовательной записью данных, последовательно пишущихся на диск и существует, отражается она на производительности совсем не так губительно, как она отражалась на старых дисках под FAT.

?? это действительно так.
Но как именно?

В UNIX FS потомках уже упомянутой выше FFS принято говорить не о “фрагментации”, а о “non-contiguous file allocation”, то есть “не-непрерывном расположении файла”. Это не то же самое, что и “фрагментация” на FAT. Достичь ситуации, когда FFS-like метод выделения блоков под запись будет вести себя также, как в случае FAT можно, но это случай из анекдота про сибирских мужиков и японскую бензопилу. Надо максимально заполнить том данными в виде мелких блоков, произвольно удалять с него небольшой процент этих файлов, а затем, на томе, заполненном более чем на 75-80% попытаться оставшееся пространство регулярно заполнять большими цельными файлами. А затем попытаться читать эти файлы линейно и последовательно.

Впрочем, справедливости ради, юзкейс совсем не такой нереальный, как выглядит сперва. Это очень похоже на использование диска домашнего компьютера, постоянно доверху заполненного всяческим домашним экстраценным (в смысле “жалко выкинуть”) хабаром, на который регулярно пишутся, смотрятся (последовательное чтение!) и стираются файлы передаваемые протоколом битторент. Но насколько такой юзкейс соответствует реальной работе типового энтерпрайз-стораджа? Ответьте себе сами.

Хотелось бы также остановиться на уже поднимавшемся в этом блоге вопросе, совершенной неочевидности ситуации с влиянием фрагментации (ну или non-contiguous allocation) при random access. Я не зря в начале акцентировал внимание на том факте, что фрагментация во времена жестких дисков на 40Mb с буферами 64Kb, интерфейсов ATA без DMA, 2-4Mb RAM, файловой системы FAT, и преимущественно однозадачных OS (и следовательно большом проценте sequental-операций) была действительно серьезной проблемой.

Но является ли она такой же проблемой во времена SATA-2 6Gb/s, буферов по 16Mb, памяти в 4-8GB и при этом подавляющем количестве random-операций к диску и его файловой системе, давно не FAT, к которой обращается очень многозадачная, а вдобавок, в наше время повсеместно победивших гипервизоров очень много очень многозадачных OS?

Есть основания предполагать, что – нет. Не является.

С точки зрения банальной логики, случайное обращение к случайно распложенным данным, мало чем отличается для диска от случайного обращения к последовательно расположенным данным. Случайность, как известно, в квадрат не возводится. Что в первом, что во втором случае это 100% random access, общепринятый на сегодня режим для анализа и тестирования производительности (см. стандартные паттерны IOmeter).

Много ли вы знаете реальных задач, подразумевающих sequental access? Ну то есть не “копирование ISO в тоталкоммандере”? Я вот знаю, сходу, только две. Это backup/restore, и работа с логами базы данных, которые, обычно, пишутся и читаются в sequental.

Ну, какие есть решения для backup/restore у NetApp, не требующие тупо “лить гигазы” вы, если читаете меня внимательно, уже знаете. Что же, допустим, с логами и прочим?

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

В каких же случаях растет non-contiguos file allocation? Очевидно, что основная причина – нехватка цельных последовательных фрагментов пустого пространства. Происходит такое может, в первую очередь, при большом объеме записи изменений, одновременно с недостатком свободного места на диске. То есть вроде и есть на диске место, формально, а на деле все эти гигабайты – место из под удаленных ранее, и уже фрагментированных файлов. Нужно OS записать протяженный кусок, но диск уже заполнен, остались только кусочки здесь и там.
Поэтому при исчерпании свободного места на диске под файловыми системами семейства FFS (и NTFS), начинает резко, значительно резче обычного для таких FS расти “фрагментация”  (“нонконтигация”. Ужас. Как-то бы придумать правильный термин на русском).

??менно этим эффектом объясняется рекомендация, например, Microsoft, не заполнять том NTFS данными более чем на 80-85 процентов. Та же ситуация будет наблюдаться и с любыми другими файловыми системами, использующими алгоритм выделения памяти, сходный с FFS.

Та же ситуация будет наблюдаться и в случае WAFL. Отсюда следует все та же рекомендация и в случае WAFL также – если необходимо минимизировать количество non-contiguous files, и ожидаются большие объемы записи, то старайтесь не заполнять данными диск целиком, особенно если на диск пишется и изменяется много блоков.

К сожалению, по причине закрытости внутреннего устройства WAFL нет информации как именно и какими размерами экстентов оперирует FS,  как в деталях устроены его алгоритмы размещения,  однако эксперименты показывают, что в текущих версиях размер экстента на запись составляет 128KB (он постепенно увеличивается от версии к версии, в версиях Data ONTAP (6.x) для старых систем с малым объемом памяти, типа FAS270, он был, предположительно, 32KB, в ранних 7.х - 64К).

То есть, если на файловой системе существует целостное, “одним писом”, последовательно лежащее свободное место, то контроллер не будет “слайсить” записываемый кусок данных, а вот так, “одним писом”, размером 128K, и запишет. А если таких кусков будет много, а свободное место большое, то и далее такие экстенты с последовательным содержимым вслед и уложит.

Выглядит совсем не так страшно, как рисуют в пугалках-говнилках наши конкуренты?

Давайте для тех, кто добрел до конца, постараюсь резюмировать все вышеизложенное вкратце.
Фрагментация существует, но серьезную роль в снижении дисковой производительности она играла на старых, несовершенных файловых системах, низкопроизводительных жестких дисках, малых объемах кэша, и преимущественно однозадачных OS, в характере доступ которых, следовательно, было сравнительно много операций последовательного доступа.

Сегодня, на значительно более совершенных файловых системах, производительных дисках, больших объемах кэша и постоянно 100% random access для современных многозадачных и виртуализованных OS, вклад фрагментации в снижение производительности недальновидно переоценивается и ситуация с ней излишне драматизируется.

Фрагментация (или, в случае NetApp и прочих UNIX-like FS, будем выражаться правильнее – non-contiguous file allocation) – существует, и в правильных OS (а Data ONTAP, безусловно, “правильная”) имеются средства корректировки и противодействия явлению “дробления последовательности размещения файловых записей”.

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