Откуда вообще берется фрагментация?

Так что же там на самом деле происходит с фрагментацией на 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, позволяет недобросовестным людям легко вводить в заблуждение относительно “проблемы фрагментации”. Возможно эта статья, при всем ее несовершенстве и поверхностности, побудит кого-нибудь поглубже разобраться в теме, и сложить собственное, компетентное, а не “по рассказам стариков”, мнение о данной проблеме.

12 комментариев

  1. Алексей:

    А вот в статье http://vmblog.com/archive/2010/12/16/how-ntfs-causes-io-bottlenecks-on-virtual-machines.aspx так же проводят разбор работы NTFS и рекомендуют проводить дефрагментацию (любопытны цифры во второй части).

  2. Алексей:

    >

    Было бы странно слышать другое мнение от президента CEO компании Raxco, цитирую: “Raxco Software, a leader in defrag for 30 years, offers one of the best disk defragmentation software services available.”:)

    А если серьезно, то я нигде не говорю что дефрагментация _на физических дисках_ вредна. Нет, не вредна. Другое дело, что и вредность _фрагментации_ в сегодняшних условиях очень часто переоценивают. Об этом и пост.

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

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

  3. Александр:

    FLARE 30… чисто поржать… есть дефрагментация :))))

    >./naviseccli -h CX4 getall|grep -i per
    Name of the software package: FLARE-Operating-Environment
    Percent defragmented: 100
    Percent expanded: 100
    Percent defragmented: 100
    Percent expanded: 100
    Percent defragmented: 100
    Percent expanded: 100
    Percent defragmented: 100
    Percent expanded: 100
    Percent defragmented: 100
    Percent expanded: 100
    Percent defragmented: 100
    Percent expanded: 100
    Percent defragmented: 100
    Percent expanded: 100
    Percent Complete : 100

  4. villain:

    Александр:
    Вам можно смеяться лишь на собой, но она всегда там была
    Это другая “фрагментация” …
    У любых “блочных” устройств она тоже есть.
    Для примера:
    Допустим есть рейд группа - мы создаем несколько LUN-ов, а потом удаляем в “серединке” LUN - появилась фрагментация рейд группы …

  5. Александр:

    villain:

    За себя я как-раз рад, что могу фильтровать то, что мне говорит EMC про NetApp и фильтровать то, что мне говорит NetApp про EMC и то, что ни тем ни тем мне не получится навешать лапши на уши. А также понимать что в EMC не договаривает… а именно EMC ну очень любят не договаривать…

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

  6. Так, давайте поспокойнее. :-/

  7. villain:

    Александр?
    При чем здесь EMC? Вы путаете теплое с зеленым. Внешнюю и внутреннюю фрагментацию и их взаимосвязь в блочных системах хранения и системах хранения эээ “на файлах/файловой системе”. Вы в большинстве блочных систем даже LUN создать не сможете больше чем непрерывное пространство на блочных устройствах (сюда даже можно включить всякие raid контроллеры 8-)).

  8. Nimdan:

    Ну villain, ну красавчик. А где же ответ Александра?

  9. bbk:

    Меня долго терзало это выражение:
    WAFL может писать куда угодно, НЕ значит, что она в самом деле пишет куда угодно.
    Почему это так? Почему в названии есть “запись повсюду”, но её по-факту нет? Или же она таки там есть?!

    Несколько раз вчитался в WP3002 про WAFL, пункт 3.2. В то время как многие другие ФС пишут метаданные только в выделенное место под них, у WAFL ситуация другая. Похоже, что в названии WAFL, когда говорят про запись “повсюду” имеют ввиду возможность записи метаданных повсюду (т.е. хранение метаданных в файле), а не записи повсюду самих данных.

    После такого заключения становится понятна логика приведённого выражения и все вопросы снимаются.

  10. bbk:

    > Почему это так?

    Потому что так лучше работает :) Разве это плохо?

    > Почему в названии есть “запись повсюду”, но её по-факту нет?

    А чем не устраивает объяснение “может писать “повсюду”, но пишет так, чтобы было оптимальнее для работы и производительности”?

    > Несколько раз вчитался в WP3002 про WAFL

    WP3002 описывает устройство WAFL по состоянию на 1993 год. Учитывайте это. Например там совсем не отражены особенности работы с aggregate и FlexVol.

    > когда говорят про запись “повсюду” имеют ввиду возможность записи метаданных повсюду (т.е. хранение метаданных в файле), а не записи повсюду самих данных.

    Это тоже верно.

  11. bbk:

    По большому счёту я хотел разобраться только с названием. А именно с “Write Anywhere” - эта часть названия вносила неоднозначности. Теперь всё ясно.

  12. bbk:

    На самом деле там еще роль играет аббревиатура, которой хотели пошутить. Ну знаете все эти гну-линуксные аббревиатурные шутки, типа GNU is Not UNIX, и прочее.

    Исторически устройства хранения NetApp стали называться Appliance. Наиболее популярный домашний Appliance в США это “тостер”, причем у них тостером называется не только знакомый нам, но еще довольно эндемичное устройство, скорее долженсвующее называться “вафельница”, это такой нагревательный девайс, пекущий рубчатые лепешки из теста, которые называются у них “вафли” - Waffle.
    Отсюда технокаламбур - внутри “тостера” (toaster) наодятся “вафли” (WAFL).
    Поэтому название файловой системы подгоняли под уже готовую аббревиатуру. :) Поэтому она, кстати, не WAFS, а WAFL.

Оставить комментарий

20/0.154

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.