Файловая система ReFS

Недавно вляпались в замечательный сбой новой модной файловой системы ReFS.

Симптоматика, оказывается, известна.

http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/7abf7f65-1f0f-4766-8894-ae56b85b3700

http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/171a1808-157e-4ef9-b0dd-8a507ff6fcef

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

Это всё при выключенном кэше записи, замечу.

Это охуенно, господа.

Столько разрабатывать мегаустойчивую файловую систему, которая такая-то устойчивая и надёжная, такая-то покрытая вся чексуммами и избыточностью, как прокажённый коростами, что в результате:

1. Техподдержка МС вообще не знает, с какой стороны браться за такие инциденты, потому что уверены, что система мегаустойчивая и с ней такого не бывает, поэтому рекомендуют строго восстановление из бэкапа.
2. Штатные утилиты вообще не умеют лечить ReFS, потому что она «неубиваемая».

Дело понятное, что МС ускоряет скорость выхода новых продуктов. Но если это будет сопровождаться таким падением качества, то будет только хуже. Уже возвращаются старые присказки «до первого сервиспака лучше не трогать» (в случае с UR для Exchange — до пятого, притом желательно второй ревизии). Замечательно, да.

Это, конечно, реклама NTFS.

Реклама
Файловая система ReFS

Файловая система ReFS: Один комментарий

  1. 123456qwertyu:

    > Дело понятное, что МС ускоряет скорость выхода новых продуктов. Но если это будет сопровождаться таким падением качества, то будет только хуже.

    На мой личный взгляд, качество продуктов от МС в основном растёт, и мало какая софтовая компания обеспечивает аналогичный уровень качества. У меня присказка даже есть: «если вы считаете продукцию MS глючной, вы просто маловато работали с софтом от HP, IBM, Symantec и Kaspersky». ReFS — это, конечно, epic fail, от которого не застрахован никто, но у коллег и конкурентов подобные epic fails встречаются ничуть не реже.

    Меня удручает другое. Мне печально тихое дропанье привычного функционала, а также постоянные переделки.

    Возьмём, скажем, Exchange. Начиная с 2007 его разбили на роли и запилили 100500 способов репликации БД. Если разбиение на роли выглядело относительно логичным, то репликационный функционал был чрезмерно переусложнён и избыточен. Ладно, в 2010 исправили ошибки, ввели DAGs, оставили разбиение на роли. Казалось бы, Рубикон перейдён, архитектура стабилизировалась, далее будут вводить новые фишки… ан нет, началась пляска с режимом Hosting. Стоило ли его вводить, обнадёжить кучу кастомеров, чтобы потом дропнуть и заявить, что при желании сделать Hosted Exchange нужно запиливать своё решение или покупать его у сторонних вендоров? Ну не вводили бы этот режим, было бы в итоге лучше, а то странноватый режим-то вышел, поддерживающийся только в конкретном сервис-паке… А дальше снова началась свистопляска, ибо вышел 2013, в котором роли, фактически, упразднили, оставив только CAS и Mailbox, к которым тоже есть свои вопросы. Архитектура вида «CAS+Mailbox» является совершенно логичной, и я не очень верю, что она никому не пришла в голову ещё при разработке 2007-й версии. Стоило ли запиливать такое дикое количество кода, чтобы отказываться от него через пять лет? Стоило ли лепить такое количество сильно различающегося софта, который нужно поддерживать? Заявления из пресс-релиза о том, что «много ролей было сделано для возможности load-balancing, но потом проблемы с производительностью были решены и от ролей стало возможно отказаться», если честно, выглядят или ложью, или фразой на уровне «знаете, у нас не нашлось грамотного архитектора, и из-за этого мы потеряли кучу человеко-часов наших программистов». А о количестве потерянного программистского времени можно судить, к примеру, по тому, что они не успели доделать роль Edge и лишь оправдываются, что «можете использовать 2010-й, он совместим, а мы, возможно, успеем доделать Edge к SP1». Нет, я не могу пожаловаться, что Exchange плохо работает: и 2007, и 2010, и 2013 вполне стабильны, производительны и предсказуемы. Но постоянные архитектурные переделки удручают.

  2. 123456qwertyu:

    2chivemind :

    В теории — может, и способна. А на практике у меня на рабочей машине NTFS делает снимок полутерабайтника за минуту-две. Восстановление тоже не мгновенно происходит.

    System Restore – это не снепшоты. Снепшот таки делается мгновенно, а уж потом из этого снепшота делается “бекап”. До сих пор не понимаю логику подобного решения.

    При чём тут System Restore? Мы про Volume Shadow Copy говорили вообще-то. Про снимки томов с данными.

  3. 123456qwertyu:

    fatlortroll :
    Да я не то, чтобы оправдываю разрабов ReFS, но с таким подходом можно и до сушения кошек в микроволновке докатиться. А чо, в инструкции не написано-же, что нельзя!
    Своя голова на плечах тоже должна быть. И не только для поесть в неё.

    А как бы тут спасла голова? Это банальный баг в коде, предсказать который логически невозможно. Или вы про нерассуждающий консерватизм вида «до второго сервиспака нельзя, потому что нельзя, потому что я считаю, что нельзя»?

  4. 123456qwertyu:

    Нет, ну это несерьезно. Бекап на том же физическом носителе, что и сама бекапируемая информация? Особенно охуенно слышать такое от Карманова – уберпрафисианала и инструктора.

    Во-первых, я не Руслан. Во-вторых, да, бэкап первой очереди снапшотами на отказоустойчивом хранилище, бэкап второй очереди — средствами metrocluster (по возможности), и только третьей очереди — классическим методом на лентах или ещё чем. А как, по-вашему, ещё десятки и сотни тер хранить?

    Ни одна гипернадежная ФС не спасет от самого обычного потопа (сервер то небось не в контейнере в датацентре, а в самом обычном офисе с самой обычной городской инфраструктурой).

    Metrocluster спасёт. Делаются две отказоустойчивые реплицируемые СХД в разных ДЦ с единым namespace и в случае уничтожения одной из них или даже целого ДЦ всё подхватывается другой.

    Да чего там потоп – журналы со снепшотами гарантируют сохранность ФС (но не ДАННЫХ) только при корректной работе “железа” (ну будет контроллер молча заменять данные в каждом третьем запросе на запись на Fizz, а в каждом пятом – на Buzz и каким образом ФС должна обеспечивать сохранность данных?).

    Во-первых, железо тоже делается дублируемым и отказоустойчивым. Сейчас уже даже самые младшие хранилки вроде IBM DS3500 имеют два контроллера в Active/Active кластере с двумя БП и с возможностью сборки массива со страховкой от потери полки. Во-вторых, ФС может иметь свою ECC, кто мешает?

    Снепшоты – это не замена бекапам, а просто быстрый способ избежать восстановления из “настоящих” бекапов в некоторых (пусть даже и большинстве, но далеко не во всех) случаях.

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

  5. 123456qwertyu:

    Попытки поднятия данных из под обломков рухнувшей ФС займут сильно меньше времени? Кроме того, товарищ жаловался, что данные критичны, и нужны вот прям щас.

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

    А бэкапить такие объёмы — на специализированное, протестированное и гарантированно надёжное хранилище.

    Ну а сроки восстановления вы куда денете? Ещё раз: я не против бэкапов вообще, но бэкапы — это last resort на случай предельной аварии вроде пожара в ДЦ, а не штатное средство восстановления при любом отказе.

    А на практике у меня на рабочей машине NTFS делает снимок полутерабайтника за минуту-две. Восстановление тоже не мгновенно происходит.

    У меня 1 Тб с 2 млн. файлов на RAID 10 из 6 пятнадцатитысячников снапшотится секунд 7-15, в зависимости от нагрузки… В любом случае, согласитесь, единицы минут лучше десятков часов или даже нескольких суток.

  6. 123456qwertyu:

    Руслан, большое Вам спасибо за почтовую рассылку об этом сбое. Я как раз собирался с ReFS поиграться, и, возможно, Вы уберегли меня этой рассылкой от неприятностей, за что я Вам очень благодарен.

  7. Ну, размещать на новой, необкатанной ФС данные, которые «very sensitive and should be restored» — это, конечно, неебически смелое решение. Интересно будет узнать, из-за чего она не может самопочиниться.

    1. На этой ФС нигде не написано, что она игрушечная, более того — позиционируется она как раз наоборот, как убер-устойчивая. Если у нового серверного продукта надо телепатически делить новые фичи на «настоящие» и «понарошку», то непонятно, кто и зачем выпустил такой серверный продукт.

      1. Консервативность и осторожность ещё не отменяли. Вон, норот на WinXP/WinServer2003 до сих пор в большом количестве сидит, и с подозрением смотрит на семёрку (про win8 вообще молчу), а тут 18 ТБ критических данных без резервирования забросить на только вышедшую ФС… Слабоумие и отвага.

        1. С аргументом «ну ведь должны же быть бэкапы» можно тогда вообще любое фуфло выпускать и на последствия класть. Сдохло и сдохло, восстановите, кто не восстановит — лох и сам виноват. Замечательный подход получится.

          1. Да я не то, чтобы оправдываю разрабов ReFS, но с таким подходом можно и до сушения кошек в микроволновке докатиться. А чо, в инструкции не написано-же, что нельзя!

            Своя голова на плечах тоже должна быть. И не только для поесть в неё.

        2. 123456qwertyu:

          Не всё и не всегда зарезервировать классическим бэкапом можно. Представьте себе те самые 18 Тб — куда их бэкапить и сколько это займёт времени? Ну, скажем, 8 Гбит у нас SAN оптика, это около 800 метров в секунду. Ну, допустим, бэкап-хранилка действительно способна 800 метров в секунду записать, а бэкапящийся массив способен с такой же скоростью читать, не оказывая значительного влияния на работу клиентов. 18 тыс. метров со скоростью 800 метров в секунду — это 6 часов 15 минут на бэкап! И это мы посчитали безумно оптимистичный вариант с очень шустрыми дисковыми массивами и хорошей SAN. На деле в случае среднего железа и имеющей место нагрузки такой объём будет бэкапиться сутки-двое.

          В силу этого, сейчас предпочитают строить сильно отказоустойчивые хранилки без SPOF, а бэкапить — средствами снапшотов файловой системы. ФС способна сделать снапшот за секунду вне зависимости от своего размера и за ту же секунду откатиться назад при необходимости. И ReFS именно для этого и разрабатывалась — чтобы служить фронтэндом высоконадёжных кластеризованных хранилищ, в которых роль бэкапов выполняют снапшоты. И именно поэтому её падение настолько печально выглядит: такие вещи просто не имеют права падать, вообще никогда и никак.

          1. > те самые 18 Тб – куда их бэкапить и сколько это займёт времени?
            Попытки поднятия данных из под обломков рухнувшей ФС займут сильно меньше времени? Кроме того, товарищ жаловался, что данные критичны, и нужны вот прям щас. Были нужны. А бэкапить такие объёмы — на специализированное, протестированное и гарантированно надёжное хранилище.

            > На деле в случае среднего железа и имеющей место нагрузки такой объём будет бэкапиться сутки-двое.
            18 ТБ критичной информации ну никак не могут быть расположены на «среднем железе», если не хочется повторить вышеописанный сценарий. В данном случае потери по деньгам получились несопоставимы со стоимостью высококачественного оборудования для резервного копирования.

            > ФС способна сделать снапшот за секунду вне зависимости от своего размера и за ту же секунду откатиться назад при необходимости
            В теории — может, и способна. А на практике у меня на рабочей машине NTFS делает снимок полутерабайтника за минуту-две. Восстановление тоже не мгновенно происходит.

          2. Нет, ну это несерьезно. Бекап на том же физическом носителе, что и сама бекапируемая информация? Особенно охуенно слышать такое от Карманова — уберпрафисианала и инструктора.

            Ни одна гипернадежная ФС не спасет от самого обычного потопа (сервер то небось не в контейнере в датацентре, а в самом обычном офисе с самой обычной городской инфраструктурой). Да чего там потоп — журналы со снепшотами гарантируют сохранность ФС (но не ДАННЫХ) только при корректной работе «железа» (ну будет контроллер молча заменять данные в каждом третьем запросе на запись на Fizz, а в каждом пятом — на Buzz и каким образом ФС должна обеспечивать сохранность данных?). То есть если ФС ушла в «самолечение» и вышла оттуда девственно чистая, но при этом абсолютно корректная — Вы не можете предъявлять претензий (есть еще ФС транзакции — TxF — но насколько я помню, в нынешней инкарнации ReFS их все равно не поддерживала).

            Снепшоты — это не замена бекапам, а просто быстрый способ избежать восстановления из «настоящих» бекапов в некоторых (пусть даже и большинстве, но далеко не во всех) случаях. Да, ФС, не должна была самоубиться, но почему толстячки с лора и двача должны убеждать инструкторов самого лучшего учебного центра Москвы (а то и вообще мира — кто там знает амбиции этого вашего Карманова), что собственные мозги и капелька здравого смысла еще никому не вредили.

          3. > Бекап на том же физическом носителе, что и сама бекапируемая информация? Особенно охуенно слышать такое от Карманова

            Где же это я такое порекомендовал/написал, можно уточнить?

        3. 123456qwertyu:

          Народ на них обычно сидит не из-за подозрений, а из-за отсутствия сертификации в «органах» (давно ли семёрку ФСБ лицензировала?), а также из-за жадности (ну мы же за эти лицензии заплатили и оно работает, чего ради мы должны снова деньги тратить?).

          От себя могу сказать, что после XP/2003 семёрка и 2008 R2 были как глоток воды в жаркий день.

          1. В теории — может, и способна. А на практике у меня на рабочей машине NTFS делает снимок полутерабайтника за минуту-две. Восстановление тоже не мгновенно происходит.

            System Restore — это не снепшоты. Снепшот таки делается мгновенно, а уж потом из этого снепшота делается «бекап». До сих пор не понимаю логику подобного решения.

    1. Было бы удивительно, если бы я порадовался такому-то охуенному успеху и качеству новой ФС.

  8. Svart Testare:

    Ахуеть! А мы как раз вот на проекте собрались опробовать Windows Server 2012 для виртуализации и эту файловую систему тоже.
    Будем теперь начеку!

    1. 123456qwertyu:

      Windows Server 2012 отлично работает в качестве гипервизора. Разница с 2008 R2 — как между небом и землёй. Проблем, на самом деле, куда меньше чем с предшественником.

      Но ReFS я не пробовал, а после этого случая так и вовсе отложу эксперимент на пару лет, пока её не вылижут.

Обсуждение закрыто.