Комментарии 38
И речь идет не о том, что нужна специальная файловая система, с преферансом и арфистками. А просто новый вариант блочного устройства, работающий с существующими ФС. Или концепция изменилась?
https://blog.westerndigital.com/storage-architectures-zettabyte-age/.
Все дровишки по ссылкам в конце статьи, очевидно.
UPD А так проверил — все это в HGST разрабатывалось еще в 2012
www.storageconference.us/2014/Presentations/Panel4.Bandic.pdf
Тогда я это и читал.
Похоже, американские маркетологи WD как дети малые разгребают огромную кучу игрушек, доставшуюся им от японцев. Понимают мало — но рады как слоны.
Эти операции, по сути, значительно сокращают ресурс контроллера твердотельного накопителя и приводят к преждевременному отказу диска.
Интересная информация. И новая для меня. А я думал память изнашивается.
Откуда дровишки?
И ведь нельзя сказать, что автор перепутал память с контроллером — про память чуть ниже тоже пишет
Плюс, не стоит забывать и о постоянных «лишних» операциях чтения-записи, которые сокращают ресурс памяти
Сейчас контроллеры SSD стали, конечно, надежнее, и проблема не такая массовая, как 8-9 лет назад, когда стали появляться первые популярные линейки SSD в рознице. Однако отказ контроллера и полная потеря доступа к данным — все еще главная проблема SSD с архитектурной точки зрения и в плане «надежности» хранения по этому параметру HDD все еще далеко впереди. Именно снижение нагрузки на контроллер может немного сдвинуть баланс в сторону более широкого применения SSD в Enterprise-сегменте, особенно в плане работы с БД.
Ну как же. Если вы отпаяете контроллер и положите его в сейф, срок его службы будет бесконечным!
Если контроллер перегревается при работе — а это нередко так, ведь далеко не всегда он обеспечен нормальным охлаждением — ресурс неизбежно падает.
Если по какой-то причине охлаждения недостаточно и контроллер SSD нагрелся до опасной температуры, он должен снижать свою частоту или сразу выключаться, как это давно реализовано для ЦПУ, а не сгорать, уничтожая данные. Много вы видели ЦПУ у которых ресурс закончился?
Много вы видели ЦПУ у которых ресурс закончился?
Очень много.
У разогнанных CPU (и GPU), просто горячих серий процессоров, зависания, перезагрузки и отказы — обычное дело. Потом они даже в простое выдают 60-70 градусов и это не лечится снижением частоты.
Из моей (правда уже не свежей практике) из СЦ — соотношение 1 к 15и примерно
Полностью поддерживаю. SSD не разгоняют. И их CPU вполне должны норм жить даже при 80-90°C (но не больше)
Уже́ сейчас вполне доступны модели по 2ТБ в формате M.2. E.g., Samsung 970 EVO.
Типовая жалоба — перегрев при длительной записи, с последующей просадкой производительности. То, что MLC «плывёт» с повышением t° — научный факт. Вопрос лишь в том, насколько удачно удалось выставить баланс температура-производительность у конкретной модели. С т.з. вероятности таки продолбать данные.
Погодите-погодите — речь про перегрев микросхем ПАМЯТИ (оно же — MLC ) или самого контроллера (чипа основного, который ARM с прибабахами)?
Именно снижение нагрузки на контроллер может немного сдвинуть баланс в сторону более широкого применения SSD в Enterprise-сегменте, особенно в плане работы с БД.
Куда его еще двигать? Весь интерпрайз давно переехал на ссд. Они давно обошли hdd в плане надежности.
Именно снижение нагрузки на контроллер
Откуда вообще взялось это? ZNS в первую очередь предназначен для повышения эффективности работы с SSD, которые внутри слишком сложные нынче с их несколькими уровнями кэширования. Особенно это касается QLC, на который большие надежды. Предлагается убрать все абстракции и дать ядру ОС понимание и контроль над тем, что творится в устройстве. При чем здесь снижение нагрузки контроллера и продление срока его службы (непонятно с чего вдруг это повысит его срок службы вообще)?
А если взять обычную файловую систему, но увеличить размер кластера (допустим до 1 Мб), чтобы он совпадал с размером блока записи/стирания? если нужно хранить много мелких файлов, чтобы место не пропадало, можно обойтись костылями вроде squashfs на диске одним крупным файлом + overlayfs в памяти, файлы обновляются в памяти, а при фиксации данных на диске squashfs обновляется и данные пишутся этими крупными блоками. Если изменений немного по сравнению с общим размером каталога, лучше записать отдельный squashfs с изменениями вместо того, чтобы обновлять основной.
Реальная система может использовать не костыли со squashfs/overlayfs, а что-то другое, но работающее по такому же принципу, собираются блоки данных из изменённых данных большого размера в памяти, потом пишутся на диск сразу большими блоками. Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.
Хотя на самой ФС все равно какая-то оптимизация нужна, чтобы её внутренние структуры эффективно работали с большим размером кластера.
Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.
Это как раз фатальный недостаток. Если мы считаем, что можем хранить данные в памяти и записывать только по настроению, то нам не нужны такие заморочки с файловой системой. Мы можем реально буферизировать кучу операций и потом аккуратно скопом в нужном порядке записывать.
Но файловая система по-позможности должна писать максимально быстро на диск. Потеря данных на кеше очень неприятная для серьёзных систем. Да и для несерьёзных, тоже.
А если сделать кэш на энергонезависимой памяти? например, RAM памяти с батарейкой или SSD небольшого объёма с небольшим размером блока и большим числом допустимых перезаписей?
тогда мы можем писать на основной диск по настроению (или после заполнения кэша), но при внезапном отключении питания данные не потеряются. И этот процесс будет контролироваться операционной системой (например, если приложение последовательно пишет данные большими блоками, то их можно сразу сохранять на основной диск, а если пишет вразнобой мелкими блоками — как-то объединять их в кэше и потом переписывать на основной диск).
Вопрос, зачем такое в ОС тащить? Далеко не для всех нагрузок такое пойдет. Обязательно появится кто-то, кому этого недостаточно. Ведь скорость будет ограничена этим кэширующим слоем, а это очень большая проблема. Теже базы данных они же примерно так и работают. В wal всегда пишутся все транзакции, а в основную базу можно скидывать в фоне большими блоками. Приложение куда лучше знает, как ему это делать оптимально, нежели ядро, которое чаще мешает только. Поэтому лучше дать этому приложению доступ к дискам, а оно само разберется. ZNS как раз про это. Вон еще key-value SSD изобрели — идеально ложится на внутреннее устройство флэш.
Поэтому лучше дать этому приложению доступ к дискам, а оно само разберется.
именно поэтому Оракл и Aerospike работают с неразмеченными хранилищами (=без ФС). И только тот же постгрес надеется на ядро, а потом имеем — https://habr.com/ru/post/472684/
Ещё в порядке бреда могу ещё одну идею накидать, что можно делать: не писать данные на диск, а закидывать их на другой компьютер (в другом физическом месте) по сети. В результате сбои не будут одновременно и можно будет восстановить данные. Байтики по сети не изнашиваются, так что может хорошо продлить срок службы. :)
В результате сбои не будут одновременно
ничего не гарантирует ) сбои могут быть и одновременные.
Байтики по сети не изнашиваются, так что может хорошо продлить срок службы. :)
только если байтики целиком с избыточностью в сеть передавать. И пока они бегут туда-сюда по каналам связи все ок. ))))
ничего не гарантирует ) сбои могут быть и одновременные.
Допустимый риск. в RAID тоже два диска могут одновременно выйти из строя, но в целом на 1-ом рейде вполне живут.
только если байтики целиком с избыточностью в сеть передавать. И пока они бегут туда-сюда по каналам связи все ок. ))))
Я имел в виду, что на другом компьютере хранить в памяти всё, так что там диск не тратить. Но поскольку идея бредовая можно и в pingfs хранить.
Т.е. основная моя идея этой всей хрени: минимальные записи на диск, путём резервирования внешним кешем, который для простоты представляет из себя компьютер.
закидывать их на другой компьютер (в другом физическом месте) по сети
Собственно, на этом и держатся распределенные базы. Они позволяют себе вольности в записи на локальное хранилище, потому что при сбое с большой вероятностью будут живы реплики на других хостах.
Я выше задавал вопросы из предположения, что хоть что-то из изложенного — правда. Потом гуглил глубже
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 зонированных блочных устройств. Но эта поддержка не на уровне файловой системы, а ниже, ср
То есть никакой специальной файловой системы нет. Есть какая-то эмуляция для обычных файловых систем, ничего не знающих о зонированных блочных устройствах. И есть более эффективная поддержка для ФС которые о таких устройствах имеют представление.
Насколько я помню — некоторые разработки велись в области интеграции такой поддержки в ZFS (грубо говоря метаданные и малые файлы храним в CMR зонах, данные сверх заданного размера — в SMR — подобно Special устройству в OpenZFS)
Но, насколько мне известно, пока в ZFS поддержка не готова. Возможно, она готова для других реально существующих ФС.
Повторяю вопрос к автору — откуда дровишки про
разработку новой файловой системы DZS?
Вот же ж пристал к человеку…
Маркетингу сказано — если завтра на хабре не будет жареной статьи, то на корпоративной пьянке встрече послезавтра все получат подарки от Деда Мороза, а муректологи — бегунок от отдела кадров.
Что непонятно-то? Человек высасывает выкручивается из последних сил.
PS. а бестолковый непрофессиональный муректолог — беда интернациональная.
Повторяю вопрос к автору — откуда дровишки проРазгадка проста: в словосочетании Digital Zoned Storage слово «Digital» относится к Western. Однако эта файловая система «Zoned Storage» выглядит немного не так, как написал автор:
разработку новой файловой системы DZS
Есть сайт где новости пишут технически грамотные люди, там и ссылка на патчи с кодом есть и расшифровано о чём идёт речь: https://www.opennet.ru/opennews/art.shtml?num=52092
Western Digital разработала новую файловую систему для Linux-систем