Western Digital разработала новую файловую систему для Linux-систем

    На полях файловых систем редко происходит что-то новое. У нас есть FAT/16/32, NTFS, Ext4, Btrfs и другие, более экзотичные способы управления дисковым пространством. Файловая система в целом явление статичное: когда-то разработчики и инженеры придумали, как структурировать данные на диске, и с тех пор все мы этим пользуемся не задумываясь, что происходит «под капотом» на уровне железа.

    И вот теперь, компания-производитель накопителей Western Digital заявила, что активно занимается разработкой новой файловой системы DZS или Digital Zoned Storage. Основная цель новой системы — применение в промышленном оборудовании HDD и твердотельных накопителях с последующим снижением нагрузки на контроллер SSD.



    Для HDD файловая система DZS сильна тем, что упрощает традиционную схему доступа к файлам и дает пользователю удобный API для управления данным вкупе с использованием черепичной технологии записи SMR.



    Фактически, разработка будет интересна, в первую очередь, администраторам СУБД и прочим пользователям, оперирующим большим массивом статичных данных.

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

    Утверждение выше об исключительно последовательной записи файла внутри выделенной зоны дискового пространства справедлива как для HDD (в том числе и с технологией черепичной записи, которая только усиливает плюсы подобного подхода), так и для SSD.

    Наибольший выигрыш в ресурсе и производительности новая система получит, конечно же, в SSD-накопителях, которые не имеют физических ограничений на чтение разных частей диска, как это происходит с HDD. О них и поговорим далее. Этим летом система DZS официально стала частью стандарта NVMe, то есть речь идет не просто о каком-то безумном концепте файловой системы от Western Digital, а о вполне реальной разработке, которая в скором будущем может стать частью IT-рынка.

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



    Процесс сбора мусора на SSD создает регулярную нагрузку на контроллер диска: кроме необходимой пользователю операции, он еще занимается и «теневой» работой по освобождению пространства блока. Эти операции, по сути, значительно сокращают ресурс контроллера твердотельного накопителя и приводят к преждевременному отказу диска. Плюс, не стоит забывать и о постоянных «лишних» операциях чтения-записи, которые сокращают ресурс памяти и приводят к ее деградации. Ну и конечно же, именно необходимость иметь буфер памяти для проведения операции сборки мусора, приводит к обидному сокращению доступного объема SSD для пользователя.



    Western Digital в своей новой системе предлагает вернуться к практике последовательной записи и, соответственно, к последовательному доступу к файлам одной группы/приложения, для того, чтобы отказаться от постоянной сборки мусора на SSD при операциях удаления-записи.



    У предлагаемой производителем системы, кроме снижения нагрузки на контроллер и продления его жизни, есть еще и вполне ощутимый прирост в производительности. Система DZS способна обеспечить стабильно максимальную скорость записи на SDD в отличие от других файловых систем, которые из-за случайного доступа и необходимости сбора мусора во время работы, зачастую упираются в показатели на уровне 200-230 Мб/с.



    Так как Western Digital является активным членом Linux-сообщества (что, впрочем, ожидаемо, так как основные клиенты компании — дата-центры и администраторы Unix-систем), то и поддержка новой файловой системы была завезена, в первую очередь, на Linux-системы.

    Сейчас Digital Zoned Storage уже доступен для использования на Long Term Stable (LTS) версиях Kernel-ядра 4.14, 4.19 и 5.4, однако, если вы захотите воспользоваться всеми возможностями файловой системы, то стоит использовать ядро версий 5.x.



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

    • применимость файловой системы как для HDD, так и для SSD;
    • работоспособность системы с черепичной схемой записи для сверхплотных HDD 20+ Tb;
    • снижение нагрузки на контроллер SSD;
    • повышение скорости записи-чтения, что критично для БД и массивов;
    • как следствие, снижение издержек потребителей и компаний на гарантийное обслуживание.


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

    Полезные ссылки по теме





    Специально для читателей Хабра у нас 50% скидка на любые серверы и VPS любых конфигураций!

    Промокод при покупке на нашем сайте:

    habrhabr


    Промокод активен до 2 февраля 2021 года!

    Intersect.Host
    Компания

    Комментарии 38

      +3
      . То есть, например, из-за этой системы диски на 240 Gb имеют реально доступный для работы объем в ~232 Gb и так далее.

      Щито? Это всё и-за перевода десятичных гигабайт в компьютерные. А диск на 240 внутри часто имеет памяти на 256, и вот это и есть тот самый запас.
        0
        Да, ошиблись, поправили.
        +1
        Кажется мне, глядя на картинку, что и Zoned Block Command (ZBC) и Zoned-device ATA command set (ZAC) не первый год как разрабатываются. Напр.
        И речь идет не о том, что нужна специальная файловая система, с преферансом и арфистками. А просто новый вариант блочного устройства, работающий с существующими ФС. Или концепция изменилась?
          0
          Это проект WD, который они запустили еще в 2019, судя по их блогу

          https://blog.westerndigital.com/storage-architectures-zettabyte-age/.

          Все дровишки по ссылкам в конце статьи, очевидно.
            +5
            В документе, ссылку на который я привел в комменте выше стоит 2016 год. А вот что именно запустил WD в 2019 я как раз и хотел бы понять.

            UPD А так проверил — все это в HGST разрабатывалось еще в 2012
            www.storageconference.us/2014/Presentations/Panel4.Bandic.pdf
            Тогда я это и читал.

            Похоже, американские маркетологи WD как дети малые разгребают огромную кучу игрушек, доставшуюся им от японцев. Понимают мало — но рады как слоны.
          +2
          Эти операции, по сути, значительно сокращают ресурс контроллера твердотельного накопителя и приводят к преждевременному отказу диска.

          Интересная информация. И новая для меня. А я думал память изнашивается.
          Откуда дровишки?

          И ведь нельзя сказать, что автор перепутал память с контроллером — про память чуть ниже тоже пишет
          Плюс, не стоит забывать и о постоянных «лишних» операциях чтения-записи, которые сокращают ресурс памяти
            0
            Деградация памяти — логичный и понятный процесс, который происходит в какой-то степени по тому же сценарию и на блинах HDD. Однако наиболее популярный сценарий смерти SSD с полной потерей доступа к данным (то есть самый жесткий сценарий) — это как раз вылет контроллера в сторону лучшего мира.

            Сейчас контроллеры SSD стали, конечно, надежнее, и проблема не такая массовая, как 8-9 лет назад, когда стали появляться первые популярные линейки SSD в рознице. Однако отказ контроллера и полная потеря доступа к данным — все еще главная проблема SSD с архитектурной точки зрения и в плане «надежности» хранения по этому параметру HDD все еще далеко впереди. Именно снижение нагрузки на контроллер может немного сдвинуть баланс в сторону более широкого применения SSD в Enterprise-сегменте, особенно в плане работы с БД.
              +5

              А есть данные, что снижение нагрузки на контроллер продлевает срок его службы?

                +1

                Ну как же. Если вы отпаяете контроллер и положите его в сейф, срок его службы будет бесконечным!

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

                    Если по какой-то причине охлаждения недостаточно и контроллер SSD нагрелся до опасной температуры, он должен снижать свою частоту или сразу выключаться, как это давно реализовано для ЦПУ, а не сгорать, уничтожая данные. Много вы видели ЦПУ у которых ресурс закончился?

                      0
                      Много вы видели ЦПУ у которых ресурс закончился?

                      Очень много.
                      У разогнанных CPU (и GPU), просто горячих серий процессоров, зависания, перезагрузки и отказы — обычное дело. Потом они даже в простое выдают 60-70 градусов и это не лечится снижением частоты.
                        0
                        Чаще всего у таких процов выходит из строя контроллер памяти кстати. И процов, у которых его нет таких проблем на порядок меньше.
                        Из моей (правда уже не свежей практике) из СЦ — соотношение 1 к 15и примерно
                          +1
                          Это скорее означает нарушение пайки, что вызвано не просто нагревом, а постоянными циклами нагрева и охлаждения. При чем до температур совсем других — гпу около 100 градусов работать могут вполне. Плюс гонят поднятием вольтажа, что так же сильно сказывается на ресурсе. Ни то, ни другое для ссд не выглядит актуальным.
                            0

                            Полностью поддерживаю. SSD не разгоняют. И их CPU вполне должны норм жить даже при 80-90°C (но не больше)

                              0
                              Не разгоняют, но минитюаризируют.
                              Уже́ сейчас вполне доступны модели по 2ТБ в формате M.2. E.g., Samsung 970 EVO.
                              Типовая жалоба — перегрев при длительной записи, с последующей просадкой производительности. То, что MLC «плывёт» с повышением t° — научный факт. Вопрос лишь в том, насколько удачно удалось выставить баланс температура-производительность у конкретной модели. С т.з. вероятности таки продолбать данные.
                                +1
                                В домашних ПК они перегреваются, потому что стоят в месте застоя воздуха вплотную к матери. На серверном рынке никто эти m.2 кроме как для системного диска не использует. Есть u.2, у которых корпус сплошной радиатор. Есть EDSFF, которые хорошо продуваются.
                                  0

                                  Погодите-погодите — речь про перегрев микросхем ПАМЯТИ (оно же — MLC ) или самого контроллера (чипа основного, который ARM с прибабахами)?

                      +1
                      Именно снижение нагрузки на контроллер может немного сдвинуть баланс в сторону более широкого применения SSD в Enterprise-сегменте, особенно в плане работы с БД.

                      Куда его еще двигать? Весь интерпрайз давно переехал на ссд. Они давно обошли hdd в плане надежности.

                      Именно снижение нагрузки на контроллер

                      Откуда вообще взялось это? ZNS в первую очередь предназначен для повышения эффективности работы с SSD, которые внутри слишком сложные нынче с их несколькими уровнями кэширования. Особенно это касается QLC, на который большие надежды. Предлагается убрать все абстракции и дать ядру ОС понимание и контроль над тем, что творится в устройстве. При чем здесь снижение нагрузки контроллера и продление срока его службы (непонятно с чего вдруг это повысит его срок службы вообще)?
                    0

                    А если взять обычную файловую систему, но увеличить размер кластера (допустим до 1 Мб), чтобы он совпадал с размером блока записи/стирания? если нужно хранить много мелких файлов, чтобы место не пропадало, можно обойтись костылями вроде squashfs на диске одним крупным файлом + overlayfs в памяти, файлы обновляются в памяти, а при фиксации данных на диске squashfs обновляется и данные пишутся этими крупными блоками. Если изменений немного по сравнению с общим размером каталога, лучше записать отдельный squashfs с изменениями вместо того, чтобы обновлять основной.
                    Реальная система может использовать не костыли со squashfs/overlayfs, а что-то другое, но работающее по такому же принципу, собираются блоки данных из изменённых данных большого размера в памяти, потом пишутся на диск сразу большими блоками. Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.
                    Хотя на самой ФС все равно какая-то оптимизация нужна, чтобы её внутренние структуры эффективно работали с большим размером кластера.

                      0
                      Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.

                      Это как раз фатальный недостаток. Если мы считаем, что можем хранить данные в памяти и записывать только по настроению, то нам не нужны такие заморочки с файловой системой. Мы можем реально буферизировать кучу операций и потом аккуратно скопом в нужном порядке записывать.
                      Но файловая система по-позможности должна писать максимально быстро на диск. Потеря данных на кеше очень неприятная для серьёзных систем. Да и для несерьёзных, тоже.
                        0

                        А если сделать кэш на энергонезависимой памяти? например, RAM памяти с батарейкой или SSD небольшого объёма с небольшим размером блока и большим числом допустимых перезаписей?
                        тогда мы можем писать на основной диск по настроению (или после заполнения кэша), но при внезапном отключении питания данные не потеряются. И этот процесс будет контролироваться операционной системой (например, если приложение последовательно пишет данные большими блоками, то их можно сразу сохранять на основной диск, а если пишет вразнобой мелкими блоками — как-то объединять их в кэше и потом переписывать на основной диск).

                          +2
                          Ровно по такому принципу многие хранилища и работают. Тот же vmware vsan. Данные всегда пишутся на SSD диск и с него в фоне перетекают на основные диски. При потере питания кэш всегда жив.

                          Вопрос, зачем такое в ОС тащить? Далеко не для всех нагрузок такое пойдет. Обязательно появится кто-то, кому этого недостаточно. Ведь скорость будет ограничена этим кэширующим слоем, а это очень большая проблема. Теже базы данных они же примерно так и работают. В wal всегда пишутся все транзакции, а в основную базу можно скидывать в фоне большими блоками. Приложение куда лучше знает, как ему это делать оптимально, нежели ядро, которое чаще мешает только. Поэтому лучше дать этому приложению доступ к дискам, а оно само разберется. ZNS как раз про это. Вон еще key-value SSD изобрели — идеально ложится на внутреннее устройство флэш.
                            0
                            Поэтому лучше дать этому приложению доступ к дискам, а оно само разберется.

                            именно поэтому Оракл и Aerospike работают с неразмеченными хранилищами (=без ФС). И только тот же постгрес надеется на ядро, а потом имеем — https://habr.com/ru/post/472684/

                              0
                              ceph тоже свою ФС использует. Ему кстати key-value ssd подойдут идеально, ибо bluestore это RocksDB.

                              А аэроспайк думаю это больше для скорости делает, а не для надежности.
                            0
                            creker вам ответил уже, могу только добавить, что использование батарейки давно практикуется для RAID-контроллеров, которым выгодно кешировать, но страшно за целостность.

                            Ещё в порядке бреда могу ещё одну идею накидать, что можно делать: не писать данные на диск, а закидывать их на другой компьютер (в другом физическом месте) по сети. В результате сбои не будут одновременно и можно будет восстановить данные. Байтики по сети не изнашиваются, так что может хорошо продлить срок службы. :)
                              0
                              В результате сбои не будут одновременно

                              ничего не гарантирует ) сбои могут быть и одновременные.


                              Байтики по сети не изнашиваются, так что может хорошо продлить срок службы. :)

                              только если байтики целиком с избыточностью в сеть передавать. И пока они бегут туда-сюда по каналам связи все ок. ))))

                                +1
                                ничего не гарантирует ) сбои могут быть и одновременные.

                                Допустимый риск. в RAID тоже два диска могут одновременно выйти из строя, но в целом на 1-ом рейде вполне живут.

                                только если байтики целиком с избыточностью в сеть передавать. И пока они бегут туда-сюда по каналам связи все ок. ))))

                                Я имел в виду, что на другом компьютере хранить в памяти всё, так что там диск не тратить. Но поскольку идея бредовая можно и в pingfs хранить.

                                Т.е. основная моя идея этой всей хрени: минимальные записи на диск, путём резервирования внешним кешем, который для простоты представляет из себя компьютер.
                                  0
                                  Я имел в виду, что на другом компьютере хранить в памяти всё, так что там диск не тратить. Но поскольку идея бредовая можно и в pingfs хранить.

                                  В основном дц — маскишоу/пожар/потоп, данные будут недоступны от месяца до никогда. У нас есть резерв, но он весь в памяти. Что дальше?
                                0
                                закидывать их на другой компьютер (в другом физическом месте) по сети

                                Собственно, на этом и держатся распределенные базы. Они позволяют себе вольности в записи на локальное хранилище, потому что при сбое с большой вероятностью будут живы реплики на других хостах.
                          +12
                          Вообще говоря, господа, нас, похоже, авторы этого поста грубо развели.

                          Я выше задавал вопросы из предположения, что хоть что-то из изложенного — правда. Потом гуглил глубже

                          1)
                          Официальный сайт проекта новой файловой системы DZS;
                          www.zonedstorage.io

                          Гуглинг по фразе DZS site:zonedstorage.io дает нулевой результат

                          2)
                          Официальная запись в блоге Western Digital;

                          В реальности «DZS» не встречается не только в этой записи — но и вообще на сайте westerndigital.com

                          3) Таким образом я не очень понимаю, откуда автор узнал, что
                          компания-производитель накопителей Western Digital заявила, что активно занимается разработкой новой файловой системы DZS

                          И прошу про эту «новую файловую систему» пояснить.

                          4) А тем временем (а точнее где-то с 2011-2012) специалисты HGST (поглощенной WD) действительно занимались разработкой поддержки в Linux зонированных блочных устройств. Но эта поддержка не на уровне файловой системы, а ниже, ср
                          image
                          То есть никакой специальной файловой системы нет. Есть какая-то эмуляция для обычных файловых систем, ничего не знающих о зонированных блочных устройствах. И есть более эффективная поддержка для ФС которые о таких устройствах имеют представление.

                          Насколько я помню — некоторые разработки велись в области интеграции такой поддержки в ZFS (грубо говоря метаданные и малые файлы храним в CMR зонах, данные сверх заданного размера — в SMR — подобно Special устройству в OpenZFS)
                          Но, насколько мне известно, пока в ZFS поддержка не готова. Возможно, она готова для других реально существующих ФС.

                          Повторяю вопрос к автору — откуда дровишки про
                          разработку новой файловой системы DZS
                          ?
                            –1

                            Вот же ж пристал к человеку…
                            Маркетингу сказано — если завтра на хабре не будет жареной статьи, то на корпоративной пьянке встрече послезавтра все получат подарки от Деда Мороза, а муректологи — бегунок от отдела кадров.
                            Что непонятно-то? Человек высасывает выкручивается из последних сил.


                            PS. а бестолковый непрофессиональный муректолог — беда интернациональная.

                            0
                            Повторяю вопрос к автору — откуда дровишки про
                            разработку новой файловой системы DZS
                            Разгадка проста: в словосочетании Digital Zoned Storage слово «Digital» относится к Western. Однако эта файловая система «Zoned Storage» выглядит немного не так, как написал автор:
                            Шок-контент
                            image
                              +1

                              Есть сайт где новости пишут технически грамотные люди, там и ссылка на патчи с кодом есть и расшифровано о чём идёт речь: https://www.opennet.ru/opennews/art.shtml?num=52092

                              +1
                              Если они файловые системы пишут так же, как операционки (прошивки) для своих NAS, то я на пушечный выстрел к ней не подойду.
                                0
                                у меня их NAS на потолке валяется уже год, проблем 0 (wdmycloud)
                                +2
                                Почему-то кажется, что это попытка продать черепичную запись, ну хоть как-нибудь. Производители смачно вляпались в скандал с SMR дисками и теперь будут намертво стоять на позиции «не баг, а фича».

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое