Файловая система WAFL — «фундамент» NetApp


    В своем первом посте в этом блоге я обещал рассказать вам о NetApp «с технической стороны». Однако прежде чем рассказать о большинстве из имеющихся в системах NetApp возможностей, мне придется рассказать о «фундаменте», о том, что лежит в основе любой системы хранения NetApp — о специальной структуре организации данных, которую традиционно принято называть «файловой системой WAFL» — Write Anywhere File Layout — Файловой Структурой с Записью Повсюду, если перевести дословно.

    Если вы сочтете, что «для Хабра» текст суховат, то потерпите, дальше будет интереснее, но не рассказать об устройстве того, что лежит в основе подавляющего большинства практических «фич» NetApp я не могу. В дальнейшем будет куда сослаться «для интересующихся» на подробное объяснение в следующих постах, о более практических «фишках».
    Так, или иначе, но почти все, что NetApp умеет уникального растет именно из придуманной в начале 90-х Дэвидом Хитцем и Джеймсом Лау, сооснователями «стартапа» Network Appliance, файловой системы. Хороший аргумент за то, насколько важной и полезной может оказаться в будущем развитии изначально грамотная и продуманная «архитектура» продукта.


    Но сначала о том, почему NetApp понадобилась своя файловая система, чем ему не подходили существующие на тот момент? Вот что говорит по этому поводу один из создателей NetApp, сооснователь и CTO компании Dave Hitz:

    «Изначально мы не предполагали писать свою файловую систему. Нам представлялось, что Berkeley FFS нам вполне подходила. Но несколько присущих ей неразрешимых проблем вскоре заставили нас заняться собственной файловой системой.

    Тестирование целостности файловой системы в случае нештатной остановки (fsck) у FFS на тот момент делалось неприемлемо медленно. С увеличением размеров файловой системы ситуация все более ухудшалась, что делало практически невозможной нашу идею объединить все диски в единый дисковый том с единым пространством.

    Мы хотели сделать максимально простое в использовании устройство. Для этого нам надо было объединить все диски в единую файловую систему. На тот момент (речь идет о начале 90-х, прим track) люди обычно создавали на каждом отдельном диске отдельную файловую систему и монтировали их вместе в общее дерево, что было неудобно и неуниверсально.

    Используя много дисков разом, с общей файловой системой на них, нам потребовался бы RAID. На то было две причины. Первая: при объединении сразу множества дисков в единую файловую систему вы рисковали потерять всю файловую систему в результате сбоя одного из множества дисков. Вторая: вероятность сбоя повышалась с увеличением количества дисков. Нам был нужен RAID, и мы решили реализовать RAID просто как часть нашей файловой системы.

    Ранее существовавшие файловые системы работали поверх RAID, и ничего не знали о том, как происходит размещение данных на физическом уровне, поэтому не могли оптимизировать свою работу с учетом этих сведений. Построив нашу собственную файловую систему, которая знала все особенности расположения данных на множестве физических дисков, и самостоятельно реализуя RAID, мы смогли максимально оптимизировать ее работу.
    Вот поэтому, посмотрев на все это, мы решили написать свою собственную файловую систему для нашего устройства.»


    (кто сказал «с блэкджеком и шлюхами»? ;)

    Главный принцип, положенный в основу функционирования файловой системы WAFL, отличающий ее от всех тогда существовавших файловых систем, может показаться немного парадоксальным: единожды записанный блок данных в составе файла в дальнейшем не перезаписывается. Он может быть только удален (очищен), но НЕ ПЕРЕЗАПИСАН.
    Таким образом любой блок данных на файловой системе может быть либо «пустым», и тогда он может быть записан, либо «записанным», и тогда он может быть либо считан, либо стерт, когда на него больше не ссылается ни одна запись вышележащей структуры. Запись (перезапись) в уже занятый какими либо данными блок невозможна по внутренней логике файловой системы.
    Необходимые же изменения содержимого записанного файла «дописываются» к нему, на свободное пространство файловой системы.



    Рассмотрим по шагам.
    На первом шаге мы видим файл, занимающий три блока на файловой системе: A, B и C.
    Шаг 2. Использующая этот файл программа желает изменить данные в его середине, которые хранятся в блоке B. Открыв файл на запись она изменяет эти данные, но FS, вместо изменения данных в уже записанном блоке B, записывает их вполностью пустой блок в области свободных блоков.
    Шаг 3. Файловая система переставляет указатель используемых файлом блоков на записанный блок B' с блока B. А так как на блок B никто больше не ссылается, то он освобождается и становится пустым.


    Такая своеобразная модель позволяет нам получить две важных особенности использования:
    • Превратить случайные (random) записи на систему хранения в последовательные (sequental).
    • Очень просто и эффективно организовать так называемые Snapshots, снэпшоты, или мгновенные «снимки» состояния данных на дисках.

    Разберем эти моменты подробнее.

    Структура организации блоков файловой системы WAFL будет понятна всем, знакомым с файловыми системами «инодового» (inodes) типа, всех многочисленных «юниксных» наследников Berkeley's FFS.
    Блоки данных файла адресуются с помощью структуры, под названием 'inode'.
    Inode может указывать как на блоки непосредственно данных файла, так и на промежуточные inodes «непрямой адресации», образуя своеобразное «дерево», где в «корне» — «корневой inode», а на самом конце ветвей — блоки непосредственно данных.



    Такую схему использует большинство «юниксных» файловых систем, что же придумано нового в WAFL?

    Поскольку, как я уже упомянул выше, содержимое уже записанных данных файловой системы не изменяется, а новые блоки к «дереву» лишь только добавляются (и остаются там, пока на них хоть кто-то ссылается), очевидно, что сохранив «корень» такого дерева, корневой inode, на какой-то момент времени, мы получим в результате полный «мгновенный снимок» всех данных на диске на этот момент. Ведь содержимое никаких уже записанных блоков (например, с прежним содержимым файла) гарантировано не изменится.
    Сохраняя единственный блок, содержащий корневой inode мы сохраняем и все данные, на которые он так или иначе ссылается.
    Это позволяет легко создавать «снэпшоты» состояний данных на дисках.
    Такой «снэпшот» выглядит как полное содержимое всей вашей файловой системы на определенный момент времени, тот, в который был сохранен корневой inode. Каждый файл на нем доступен для чтения (изменять его, конечно, не получится).



    Рассмотрим подробнее. На первом шаге у нас вновь файл, занимающий три блока файловой системы.
    На шаге 2 мы создаем «снэпшот». Как уже рассказано выше, это просто копия ссылок активной файловой системы на занимаемые файлами блоки. Теперь каждый из блоков A, B и C имеет по две ссылки. Один от файла File1, второй — от этого файла из сделанного снэпшота. Это похоже на линк в UNIX-файловой системе, но линки ведут не на файл, а на блоки данных этого файла на файловой системе. Программа изменяет данные в блоке B файла, вместо которого происходит запись нового содержимого в блок B'.
    Шаг 3. Однако старый блок B не становится пустым, так на него ссылаются из снэпшота. Теперь, если мы хотим прочитать содержимое File1 до изменений, мы можем использовать файл ~snap/File1, который обратится к блокам A, B и C. А новое содержимое доступно при чтении самого File1 — A, B' и C. Таким образом нам доступно как старое, через ее снэпшот, так и новое содержимое файловой системы.


    Как я уже сказал выше, такая организация записи на файловую систем позволяет достичь с точки зрения системы сразу нескольких важных вещей:
    • Превратить операцию random write в значительно более быструю и эффективную для системы хранения операцию sequental write (так как всю группу записей в кэше, логически предназначавшихся разным файлам в разных местах FS можно записать в один последовательный сегмент пустых блоков).
    • Делать запись на диски эффективно, «полным страйпом».

    Необычно в системах NetApp также то, что они реализовали в своей файловой системе, которая, напомню, является еще и сама себе RAID-ом и менеджером томов, необычный тип RAID — RAID type 4. Это, напомню, модель «чередование с четностью», похожая на привычный RAID-5, но диск четности выделен на отдельный физический диск (а не «размазан» по всему RAID как в type 5).

    Обычно RAID-4 редко используется «в живой природе», так как ему присущ один, но очень серьезный недостаток — его производительность, при «обычном» его использовании, упирается в производительность диска parity, на каждую операцию записи на RAID-группу приходится операция изменения на диске parity, а значит сколь ни увеличивай размер RAID-группы, ее суммарная производительность все равно упрется в производительность одного диска на запись.
    С другой стороны, RAID-4, как RAID с выделенным parity (в отличие от, например, RAID-5, «с невыделенным parity») имеет очень солидный плюс, заключающийся в возможности расширить емкость RAID добавлением дисков «мгновенно». Добавление диска в RAID-4 не приводит к необходимости «перестроения RAID», непосредственно после физического вставления HDD и добавления диска данных в уже существующий RAID, мы можем начать на него писать, расширив на него как внутреннюю файловую систему WAFL, так и лежащие поверх нее структуры, например тома данных CIFS, NFS или LUN-ы. Для устройства, изначально ориентированного на простоту обслуживания, и «не-IT-шные» компании в качестве клиентов, это было большим плюсом.
    Однако, что делать с быстродействием?

    Оказалось, что если мы пишем на RAID-4 последовательно, и «полными RAID- страйпами», то проблемы с упиранием в диск parity просто нет. Подготовленный страйп одной операцией записи заносится во все диски RAID-группы, затем ожидает сборки следующего страйпа, и «в один присест» записывает и его.

    Что же мешает делать также на любой файловой системе?
    «Random-ность» записи. Подавляющее большинство записей на современных задачах это довольно хаотические записи по пространству диска. Поскольку в классической файловой системе мы вынуждены перезаписывать тысячи, десятки тысяч блоков данных, произвольно разбросанных по пространству диска, причем обычно без какой-либо логики с точки зрения диска, становится чрезвычайно сложно собрать в кэше «полный страйп». Для этого надо либо увеличивать пространство кэша на запись, либо увеличивать время нахождения данных в нем, что повышает вероятность того, что, наконец, мы, в какой-то момент соберем нужный нам страйп в этом «паззле», и сможем сбросить его максимально эффективно на RAID.

    Однако, как вы помните, в WAFL у нас нет нужды гонять головки дисков по «блину», чтобы перезаписать пару (кило)байт где-то в середине файла. Нужно изменить данные? Не проблема. Вот там у нас большой пустой сегмент, пишите все скопившееся разом туда, а потом переставьте указатель в inode на новое место. Вся ожидающая очереди на запись группа байт разом, не гоняя по блину головки, в один прием, последовательно (Sequental), утекает на диски. Запись завершена, а значение parity, предварительно обсчитанное для страйпа, также в один прием, занесено на диск parity.

    Конечно ничто не дается даром, и превращение случайной записи в последовательную в ряде случаев может превратить «последовательное» чтение в «случайное». Однако, практика показывает, что и последовательных чтений (как и последовательных записей) в практике случается не так много, а на случайном чтении такая «размазанность» файла по файловой системе сказывается сравнительно мало.
    К тому же большой кэш чтения чаще всего успешно справляется с этой проблемой.
    Для тех же случаев, когда производительность ПОСЛЕДОВАТЕЛЬНОГО чтения действительно важна (например при резервном копировании, которое происходит в пределах файла преимущественно последовательно) на системах NetApp работает специальный фоновый процесс оптимизации, непрерывно повышающий степень «последовательности» размещения данных (то что в unix-ных FS называется 'contiguous'), при этом данные, оцененные как располагающиеся последовательно, собираются в более длинные последовательные «чанки», что облегчает их дальнейшее последовательное чтение (sequental read).

    Второй особенностью WAFL является необычная схема «журналирования». Тут надо сказать, что для 1993 года, когда появилась WAFL, журналирование все еще было довольно редкой «фичей» в файловых системах, и одной из задач при созданииWAFL была организация консистентного хранения данных и быстрый перезапуск после сбоя. В эти годы «грязный» перезапуск объемных файловых систем на UNIX-серверах зачастую вызывал запуск fsck на многие минуты, а, иногда, и часы.

    В WAFL используется несколько необычная схема, с «журналом», вынесенным на отдельное физическое устройство — NVRAM.



    NVRAM это необычное устройство. Хотя внешне оно действительно напоминает привычный сегодня кэширующий контроллер, с ОЗУ и батареей для питания его на выключенной системе, и сохранения данных в нем, принцип работы его совсем иной.

    Поступающие на систему хранения данные и команды (например операции NFS) предварительно накапливаются в NVRAM, после чего, «атомарно», переносятся на диски, создавая при этом так называемые Consistency Points (CP), «точки консистентности», «непротиворечивого состояния» (кстати CP это тоже такой специальный внутренний «снэпшот», используется тот же самый логический механизм). Операция создания CP происходит либо раз в несколько секунд, либо по заполнению определенного объема памяти в NVRAM (high watermark). Между CP состояние файловой системы полностью консистентно, а переключение на следующую CP — моментально и атомарно, поэтому файловая система всегда находится в целостном состоянии, что похоже на то, как организована работа у SQL-баз данных.

    С точки зрения системы, данные либо целиком успешно записаны, либо еще не покинули NVRAM и не попали на диски. Так как файловая система не перезаписывает свое уже занесенное на диски содержимое, то организовать «атомарность» очень просто, ситуация, когда в части блоков уже изменены данные, а в части — еще нет (например произошел программный или аппаратный сбой) попросту невозможна. Возможна ситуация, когда в часть считающихся ПУСТЫМИ блоков уже занесены новые данные, но пока не переставлен «указатель» на новый CP (моментальное действие), фиксирующий новое состояние файловой системы, она остается в консистентном состоянии предыдущего CP, и это не страшно. Если работоспособность системы будет восстановлена, запись продолжится с момента, на котором ее прервали на последнем успешном CP, и запишет лежащие в NVRAM с батарейным питанием (до недели без электропитания системы в целом) данные, те, на которых процесс оборвался, и тогда переставит CP. «Полузаписанные» данные в момент сбоя будут «на уровне ФС» считаться «пустыми» (а данные в NVRAM — его не покинувшими), пока не обновится указатель на CP.
    То есть работа системы выглядит следующим образом:

    NVRAM — системе: Пора писать CP!
    Система — NVRAM-у: Ну, поехали.
    Пишем.
    Система NVRAM-у: Как там у вас дела? Все готово?
    NVRAM: Готово, шеф!
    Система — файловой системе: Ну, с богом! Плюсадин!
    Файловая система: (инкрементирует указатель своего текущего состояния на сформированный CP) хрю!

    Вариант неудачной записи:
    NVRAM — системе: Все пропало, шеф! Диски не отвечают! Шеф? Вы здесь?
    Система (загрузившись): Уф, шоэто было? NVRAM! Замри! Файловая система — никто никуда не идет! Используем последнюю валидную запись CP перед сбоем! NVRAM — теперь повтори последнюю операцию записи, на которой прервали, с самого ее начала!
    NVRAM: Есть, шеф!

    Такая остроумная схема делает файловую систему исключительно целостной и устойчивой, вплоть до того, что многие практические администраторы за много лет работы систем NetApp никогда не сталкиваются ни с какими случаями нарушения ее целостности и с необходимостью «запускать chkdsk (fsck для жителей соседней OS-галактики;)».
    В скобках отмечу, что средства контроля целостности WAFL в системе конечно же есть, в том случае, если они вам понадобятся.

    Подробнее о устройстве и принципах работы WAFL вы сможете из авторской публикации «Создание специализированной файловой системы для файлового сервера NFS», опубликованной в 1994-м году в журнале USENIX, и описывающей базовые принципы построения WAFL. На сайте российского дистрибутора компании Netwell, в регулярно пополняемой библиотеке переведенных Best Practices можно скачать перевод этого документа.

    В следующей статье я расскажу о том, как на WAFL удалось реализовать дедупликацию данных, не замедляющую работу системы хранения.
    NetApp
    30.61
    Company
    Share post

    Comments 45

      0
      То есть файловая система у них это по сути не-SQL БД с версионностью?

      Интрересно, почему они выбрали использовать софтверный (я правильно понял) RAID, неужели хватает производительности?
        +1
        1. Ну в общем да. Первоначально в качстве «языка запросов» использовался, как ни парадоксально звучит — NFS. Пото, после того, как они добавли CIFS и FC/iSCSI все стало сложнее, но идея та же. Да, база с версионностью как хранилище записей о файлах.
        Впрочем, есть мнение, что называть WAFL файловой системой в чистом виде, как мы это понятие трактуем сейчас, нельзя. Об этом я тоже попозже напишу наверное, как соберу мысли. Но по традиции принято называть ее FS.

        2. Ну во первых помните, что WAFL появилась году в 93-м, значит начали ее разрабатывать этак в 92, не позднее. А сам термин RAID как таковой появился впервые в научной статье, опубликованной в 87-м году, так что, подозреваю, выбор «аппаратных контроллеров» достаточной мощности на тот момент был невелик :)
        Во вторых, страхи вокруг «софтверности» RAID «несколько преувеличены». Вон большие enterprise сервера SUN юзают, и ничего.
        К тому же часто у людей есть несколько превратное представление о разнице «аппаратного» и «программного» RAID. В аппаратном же не специальные наногномики байтики перетаскивают. Там точно также процессор, память, и программа на этом процессоре. То есть это есть самый что ни на есть «программный» RAID, просто на отдельном процессоре.
        Процессор системы хранения не занимается по сути ничем другим, кроме задач хранения, поэтому хорошо отлаженный «софтверный» RAID на такой системе ничем не хуже (на практике — лучше, потому что процессор обычно быстрее), чем отдельная плата с отдельным процессором.
        Просто воспринимайте всю систему в целом как такой большой RAID-контроллер в ящике. :)
        В третьих изначально системы планировались в массовый, недорогой рынок, а цены на компьютерное железо тогда были совсем не те что сейчас. И попытка использовать «аппаратный» RAID стороннего производителя резко бы увеличило стоимость решения и убило бы проект.
        В четвертых (вы не устали?;), и это, наверное, само важное, процитирую одного нетапповского инженера: «все файловые системы работают поверх RAID. Но только наш WAFL и его WAFL RAID знают друг о друге так много, что могут использовать взаимные достоинства и компенсировать недостатки друг друга при работе».
          0
          Только не надо забывать, что на процессор общего назначения аккумуляторную батарею не повесишь ;)
          Другой вопрос что в данном (WAFL) случае, это «как бы» не страшно и не обязательно.
            0
            Ну в общем да, в данном случае.
            Впрочем, многие RAID-контроллеры же работают без BBU, да, без write back, но тем не менее довольно много таких.
              0
              В аппаратных RAID батарея тот же NVRAM питает. О процессоре там речи не идет.
                0
                Ну здрасте приехали.
                А логику и подсчёт parity у raid-5/6 там кто обеспечивает?
                  0
                  Я про питание от батарейки говорил, а не про отсутсвие процессора.
                    0
                    Ну так пока сервер стоит, нафига xor-engine'ну питание? =)
              0
              Особенно радует термин «недорогой рынок». Вот S300 был недорогой, но прикрыли же лавочку. :(
              А файловая система замечательно сделана, единственный непонятный момент — как решается падение производительности записи со временем.
              Например:
              1) берем пишем файл на 99% емкости, и начинаем его усиленно менять
              2) пишем много-много-много маленьких файлов (на 50% емкости) и начинаем их усиленно менять…
                0
                В самом начале это были действительно недорогие системы, особенно в свете того, что их конкурентами были сервера Sun и Auspex, за многие десятки и сотни тысяч долларов.
                Но потом постепенно пошли большие задачи и большие системы, а зарабатывать на больших системах тривиально проще.
                Ценовая война с «китайцами» еще никому не удалась, а погубила многих именитых, тот же 3Com, например. Где он тот триком, ау. ;(

                «падение производительности записи со временем» решается правильной настройкой и правильным использованием системы.
                Вот результаты
                www.storageperformance.org/results/a00062_NetApp_FAS3040-48hr-sustain_executive-summary.pdf

                Если, конечно, ваша задача не описывается анекдотом про суровых сибирских мужиков и новую японскую бензопилу ;)
                  0
                  3com нынче, если не ошибаюсь, каким-то образом поглощен HP
                  0
                  Да не забросает меня камнями track за комментарий.

                  Ваш вопрос весьма в точку, проблема падения производительности со временем есть(и от других факторов, например заполненность агрегаты и количество непрерывных свободных мест, также недаром сразу 10% съедается на т.н. WAFL резерв, одна из задач которого как раз обеспечить наличие места для поддержания скорости записи), однако до сих пор NetApp как-то обходит её пристальным вниманием (никакой официальной статистики, никаких best practice или специальных мануалов).

                  У конкурентов и злых языков эта одна из излюбленных тем для FUD — «а зачем NetApp поставляет вместе с системой хранения программу дефрагментации???».

                  На самом деле т.н. reallocate это часть операционной системы предназначенный как раз чтобы выправить ситуацию (если возникла) с неоптимальным расположением данных на WAFL.

                  Однако как уже сказал ниже track при правильно настроенной системе такая проблема решима («правильное использование» :) ). Может появится очень не скоро (зависит от многих факторов) или не появится вообще. Самый типовый случай — расширение агрегаты новыми дисками, т.е. в одной или нескольких райд группах появляются новые диски.
                    0
                    Ситуация с фрагментацией насамом деле действительно непроста.
                    Вот, например, много лет считалось, что inode-овые (UNIX-ного типа, наследники FFS) файловые системы мало подвержены эффекту фрагментации в принципе. Тем не менее, спустя 20 лет их развития большинство новых FS имеют утилиты устранения фрагментации (пример — ext4, xfs). Значит фрагментация на UNIX действительно существует, вопреки ранее считавшемуся, и с ней надо бороться?
                    По видимому да.

                    Так что ответом на вопрос «почему поставляет» будет контрвопрос: «а почему вы не поставляете, на что надеетесь?»

                    С другой стороны, фрагментация данных мало влияет, если характер чтения фрагментированных данных — random.
                    А именно такой характер носит современный характер использования данных в многозадачных OS, в системах виртуальной серверной инфраструктуры, гипервизоров, OLTP-баз.
                    Случайное чтение случайно расположенных на диске блоков данных ничем не отличается с точки зрения seek overhead от случайного чтения последовательно расположенных данных. В обеих случаях чтение идет мелкими блоками и случайно.

                    Третий момент состоит в том, что, несмотря на то, что WAFL действительно _может_ писать данные «куда угодно», из этого совсем не слдует, что она _на самом деле_ пишет их «куда угодно».
                    Пример — использование так называемых «экстентов», то есть если система видит, что записываемые данные располагаются последовательно, то она постарается записать их в послдовательные цепочки блоков, что, конечно, снижает фрагментацию.

                    Я писал ранее про большую задачу, которую решала компания Weta Digital, и когда я связался с ее автором, среди прочего, я спросил и как он относится к проблеме фрагментации на NetApp (не скрою, я сам этой темой очень интересуюсь, чтобы сложить свое об этом представление).
                    Так вот человек сказал, что, несмотря на то, что их требования к производительности системы были чрезвычайно высоки, что они твикали буквально все, ради достижения нескольких процентов прироста (благо они использовали Linux в качестве OS узлов их гигантской рендерфермы), они _вообще_ не занимались проблемой фрагментации, сочтя ее незначительной во влиянии на производительность системы хранения в целом.

                    Безусловно можно придумать такое сочетание рабочих нагрузок и характера хранимых данных, и доступа к ним, когда это будет влиять. Но вопрос, насколько это реальная задача, не уподоблямся ли мы пресловутым сибирским мужикам, которые испытывали новую японскую бензопилу из анегдота. :)
                      0
                      Экстенты существуют по сути только для Exchange (уточнял по документации на 7.3.1, может для более поздних что-то изменилось).

                      На random чтение влиять не будет, на последовательное для NAS — мало или совсем нет (спасибо NetApp за грамотные алгоритмы кеширования) разве что система и так перегружена, для SAN — вопрос неоднозначный, что там творится на LUN в 3rd party файловой системе хрен его знает, алгоритмы вполне могут не работать (особенно если это какой-нибудь LUN c VMFS нагруженный пачкой VM, а клиент(scsi initiator) по сути один — ESX) или работать частично. Тут NetApp непричем, у всех вендоров будут те же проблемы.
                      А если считывание LUN идет на уровне Data ONTAP snapmirror например то это уже не SAN вообще.

                      Про запись уже другой вопрос. На WAFL и RAID-DP фрагментация немного иного характера чем на обычном райде или вообще одном диске. Когда страйп уже записан, а потом часть данных в нем стерта и помечена как свободные блоки то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать, что в случае WAFL может происходить довольно часто даже для random данных, особенно на заполненной агрегате, особенно на «старой», т.е. тут которую уже давно и интенсивно используют random записями.

                      WETA ж все-таки по большей части считывали данные (аж FlexCache применили), да и NAS(NFS) у них был.

                      Вопрос «а почему вы не поставляете, на что надеетесь?» весьма интересен :) Может породить еще и большую кучу малу.

                      Резюмируя, FUD на то и FUD чтобы нечестно дискредитировать вендора. Реальные проблемы могут быть на старых сильно заполненных (точнее с малым количеством длинных непрерывных свободных мест) агрегатах, где довольно много данных было перезаписано. Либо если неграмотно расширяли (добавляли малое кол-во дисков в райд группы/ создавали новые группы с малым кол-вом) и не делали reallocate после этого.
                        0
                        > Экстенты существуют по сути только для Exchange (уточнял по документации на 7.3.1, может для более поздних что-то изменилось).

                        Это у вас путаница. «Экстент» это название метода адресации данных в файловой системе (например NTFS ее тоже использует). WAFL использует экстетнтную модель размещения данных при записи, и это, разумеется, работает для всего, а не только «для Exchange»

                        > то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать,

                        Знаете, это все домыслы, потому что NetApp детали устройства нынешней WAFL не публиковал, поэому все что мы тут с вами на эту тему наспорим будут довольно «из пальца сосаны».
                        Как там обстоит дело «на самом деле» знают только в NetApp, а они не говорят.
                          0
                          Ок, я вполне верю что это так. Мы говорили про разные extent получается. Я не в курсе был что точно так же называют некий цельный кусок данных расположенный в одном месте.

                          Не из пальца. Курс PAD (Performance analysis on Data ONTAP) довольно подробно разбирает падение производительности из-за большего количества CPread (Consistency Point read) при записи.
              0
              А вы можете рассказать о фичах файловой системы WAFL на более прикладном уровне?
              Например, мне интересно:
              1. Поддерживается ли там квотирование на уровне директорий?
              2. Поддерживается ли там фича с отображением пользователю только тех файлов, к которым у него есть доступ (в терминологии MS это называется Access-based Enumeration)?
                +1
                1. Квотирование на уровне пользователей и групп есть для NAS (то есть CIFS и NFS). Квота назначается на некую структуру, которая называется QTree, с точки зрения пользователя эта папка на томе.
                Вы создаете qtree, расшариваете ее, и получаете сетевую шару квотированную по объему и, кажется, числу файлов, на юзера/группу.
                AD для CIFS поддерживается. Умеет работать с NIS и LDAP для NFS, но подробно последним не занимался, не могу сказать.

                2. А это, кажется, никто кроме Novel Netware так и не сделал, кажется.
                Обычно это все же как-то иначе реализуется сейчас.
                Но свойства «видеть ресурс» или «не видеть» — нет. К сожалению или к счастью ;) не знаю. Не делают это нынче, по моему никто не делает, знаю вот только про Netware.
                Доступ (или отсутствие его) к папке или файлу для юзера-группы, есть, конечно, как у обычного файлсервера.

                  0
                  Вы создаете qtree, расшариваете ее, и получаете сетевую шару квотированную по объему и, кажется, числу файлов, на юзера/группу.
                  А как насчёт вложенных квот? Т.е. на некую расшаренную папку назначается общая квота на группу. А на подпапки внутри неё меньшие квоты для других подгрупп или отдельных пользователей?
                  А это, кажется, никто кроме Novel Netware так и не сделал, кажется.
                  У Novell на эту фичу был патент, но он то ли истёк, то ли был выкуплен, по крайней мере у MS, начиная с Win2003-R2, это уже было реализовано.
                    0
                    Если это уже сделано в CIFS у MS, почти наверняка это будет со временем и у NetApp, насколько я знаю NetApp использует официальную лицензию MS на CIFS (то есть НЕ Samba).

                    Насчет квот подробнее сходу не могу сказать, надо в документацию лезть.
                      0
                      Тут вот мне пишут в ответ на ваш вопрос:
                      1. Вложенных qtree нет, но если нужно организовать вложенные папки с квотами, то это можно сделать создав qtree (одноуровнево) и организовав их в нужном порядке в дерево с помощью симлинков.

                      2. -accessbasedenum уже появился.
                    0
                    MS, кстати, не рекомендует ABE для больших расшаренных папок с большим количеством пользователей, т.к. это дело изрядно подтормаживает в таком случае :)
                    +1
                    Прекраснейшая статья! Даже такой дуболом в файловых системах, как я всё понял.Срочно на главную!
                      +1
                      Большое спасибо за столь развернутый и в тоже время понятный материал
                        0
                        А вот за этот пост спасибо. В прошлом я бухтел (или это был HP'ный пост?). Сухих постов на харбре не бывает, бывают либо нормальные, либо желтушные-попсовые.

                        Вы написали нормальный пост.
                          0
                          На мой вы тоже бухтели ;)
                          0
                          Жажду сравнение с GFS2 и ZFS! С графиками!
                            0
                            Ну это надо просить того, кто имел дело с ними.
                            0
                            в кои веки хорошая, годная статья. только не для этого ресурса, это всё равно что бисер перед свиньями метать.
                              0
                              Вот уж действительно вундервафля!
                                0
                                Собственно название оттуда и пошло. Это была такая попытка схохмить и скаламбурить, народ был молодой и веселый.
                                Изначальная идея, стоящая в основе NetApp — «делать компьютерные стораджи простые в использовании как бытовая техника». Типичное бытовое устройство для американца это тостер. Поэтому исторически нетапповские стораджи принято называт toaster. А что находится внутри тостеров? Вафли. (мы их чаще тостами или гренками зовем, но видимо не нашли подходящей комбинации слов для такой аббревиатуры).
                                В общем вот такую вот историю возникновения названия старожилы рассказывают
                                0
                                «Пустой» блок, который может быть записан он действительно «пустой» или просто может быть записан?
                                  0
                                  Ну специально его никто не «обнуляет», конечно, как и во всех ныне существующих FS «пустой» блок это такой атрибут файловой системы, принадлежащий данному блоку.
                                  В данном случае это значит, что на этот блок никто (ни файл активной файловой системы, ни снэпшот) не ссылается, и он считается принадлежащим пулу свободных для последующей записи блоков.

                                  Физически это обычно делается с помощью так называемо «битовой карты», если блок используется — там единица, если нет — ноль. Только в случае WAFL используется не «битовая» а «байтовая» карта, потому что блок может принадлежать либо активной файловой системе, либо одному из 256 снэпшотов, на что указывает значние байта. Когда блок не принадлежит никому, то в карте остается только 0, значит он «пуст» (никто не использует), и может быть использован под запись.
                                  0
                                  это точно делали для HDD?

                                  обычно такие фокусы с дописываем делают для флеша с его спецификой больших блоков и стерки
                                    0
                                    Это делали для HDD, да, ну какой в 93-м году flash. Но и в самом деле, сейчас выяснилось, что такая модель работы прекрасно подходит и для работы с flash.
                                      0
                                      SSD & WAFL
                                      Может это изначально и не для SSD писалось, но оказалось что запись в новое место очень даже подходит для SSD.
                                      0
                                      гениальные инженерные решения описаные отличным языком.

                                      очень, очень хорошо.

                                      автору большая благодарность.
                                        0
                                        Спасибо за статью.
                                        Несмотря на то, что довольно давно читаю о NetApp'е, многие «вещи» о WAFL, наконец для меня легли на свои полки.
                                          0
                                          отличная статья, спасибо!)
                                          ну ладно, производительность vs ZFS надо мерять, а как насчет фичастости WAFL vs ZFS?
                                            0
                                            Ну с учетом того, что WAFL пишется с 1993 года, а ZFS появилась в 2005-м, то у последней еще много что впереди. Вот в этом году у нее появилась дедупликация, которая уже есть в WAFL несколько лет, и о которой я напишу подробно в следующей статье.
                                            0
                                            а про алгоритм L2 кеширования напишете? оч интересно, что у вас вместо ARC.
                                              0
                                              Э-э. Это про что это, не совсем понял?
                                              Про Performance Acceleration Module разве только?
                                              Что-то про другое L2-кэширование в голову не приходит. Уточните.
                                                0
                                                Да, наверное про него тоже :)
                                                А в самом сторадже нет кэша для чтения? только nvram для записи/избавления от write hole?
                                                  0
                                                  Вся установленная в контроллере системы хранения память — это кэш чтения. Кэша записи, в том смысле, в каком это слово используется в других системах просто нет, только буфра OS и пространство NVRAM.
                                                  Это связано с тем, что запись производится на диски максимально быстро, и дополнительное кэширование ее почти не улучшает.
                                              0
                                              Э-э. Это про что это, не совсем понял?
                                              Про Performance Acceleration Module разве только?
                                              Что-то про другое L2-кэширование в голову не приходит. Уточните.

                                              Only users with full accounts can post comments. Log in, please.