Подстава с NVMe на Линуксе

    Доброго времени суток.

    Хотел обратить внимание сообщества на характерную особенность Linux при работе с несколькими NVMe SSD в одной системе. Особенно актуально будет для тех кто любит делать из NVMe программные RAID массивы.

    Надеюсь, что информация приведенная ниже поможет уберечь ваши данные и избавит от досадных ошибок.

    Все мы привыкли к следующий логике Linux при работе с блочными устройствами:
    Если устройство называется /dev/sda то разделы на нем будут /dev/sda1, /dev/sda2, и т.д.
    Для просмотра SMART атрибутов мы используем что-то вроде smartctl -a /dev/sda, а форматируем, и в массивы добавляем уже разделы, вроде /dev/sda1.

    Все мы привыкли к аксиоме, что /dev/sda1 располагается на /dev/sda. И, если в один день SMART покажет что /dev/sda почти сдох, — именно /dev/sda1 мы будем выкидывать из RAID массива на замену.

    Оказывается, при работе с NVMe Namespaces это правило не работает. Пруф:

    nvme list && ( smartctl -a /dev/nvme0 && smartctl -a /dev/nvme1  && smartctl -a /dev/nvme2 ) | grep Serial
    Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
    ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
    /dev/nvme0n1     S466NX0K72XX06M      Samsung SSD 970 EVO 500GB                1          96.92  GB / 500.11  GB    512   B +  0 B   1B2QEXE7
    /dev/nvme1n1     S466NX0K43XX48W      Samsung SSD 970 EVO 500GB                1          91.00  GB / 500.11  GB    512   B +  0 B   1B2QEXE7
    /dev/nvme2n1     S466NX0K72XX01A      Samsung SSD 970 EVO 500GB                1           0.00   B / 500.11  GB    512   B +  0 B   1B2QEXE7
    Serial Number:                      S466NX0K72XX06M
    Serial Number:                      S466NX0K72XX01A
    Serial Number:                      S466NX0K43XX48W
    

    Внимательный читатель по сопоставлению серийных номеров заметит, что /dev/nvme1n1 на самом деле располагается на /dev/nvme2, и наоборот.

    Р.S.

    Желаю вам никогда не удалять из RAID массива последний живой NVMe SSD.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +11
      /dev/nvme1 это символьное устройство — контроллер. В свою очередь /dev/nvme1n1 — это уже диск (аналог /dev/sda), а /dev/nvme1n1p1 — это раздел на этом диске (/dev/sda1). Соответственно /dev/nvme1n1p1 будет всегда на /dev/nvme1n1.
      А вот почему smartctl выдает что-то осмысленное на /dev/nvme0 как будто это диск, и почему это не совпадает с /dev/nvme0n1 — это вопрос к авторам smartctl видимо.
        +1
        Smartmontools мониторит NVMe устройства через их символьные устройства контроллеры. В отчетах которые присылаются по почте — тоже указывается именно символьное устройство:
        Device: /dev/nvme2, Temperature 59 Celsius reached critical limit of 59 Celsius (Min/Max 33/80)

        Собственно да, отсюда и растут ноги у подставы. Особенность работы smartctl с NVMe. В сочетании с особенностью ядра, которое назначает имена контроллерам и нэймспейсам абы-как.
          0
          Smartmontools мониторит NVMe устройства через их символьные устройства контроллеры

          Они ему вообще-то не нужны.


          # mv /dev/nvme0 /dev/nvme0_
          # smartctl -i /dev/nvme0n1
          smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-3-amd64] (local build)
          Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
          
          === START OF INFORMATION SECTION ===
          Model Number:                       Samsung SSD 960 PRO 1TB
          …

          Мониторит smartd, ему в конфиг впишите имена дисков, которые надо мониторить явно.


          Вообще, косяк smartctl лишь в том, что ему надо тут падать с ошибкой:


          lstat("/dev/nvme0", {st_mode=S_IFCHR|0600, st_rdev=makedev(0xf7, 0), ...}) = 0
          openat(AT_FDCWD, "/dev/nvme0", O_RDONLY|O_NONBLOCK) = 3
          fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
          ioctl(3, NVME_IOCTL_ID, 0)              = -1 ENOTTY (Inappropriate ioctl for device)

          А вот тут всё хорошо:


          lstat("/dev/nvme0n1", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x103, 0), ...}) = 0
          openat(AT_FDCWD, "/dev/nvme0n1", O_RDONLY|O_NONBLOCK) = 3
          fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
          ioctl(3, NVME_IOCTL_ID, 0)              = 1

          А smartd должен просто игнорировать "/dev/nvme\d+".

            0
            Тут варианты есть. Можно покопать smartd. Можно копать в сторону udev rules. Можно просто скрипт написать который правильно переименует устройства.
            Тут главное, — знать о проблеме, т.к. с настройками по-умолчанию можно ошибиться по-незнанию.
              0

              Не надо устройства переименовывать. Там всё уже правильно названо.


              Вот что надо сделать со smartd.conf:


              #!/bin/bash
              conf="/etc/smartd.conf"
              echo "DEFAULT -m root -M exec /usr/share/smartmontools/smartd-runner" >$conf
              find -L /dev/disk/by-path -type b -not -name "*-part*" >>$conf

              Исправить по вкусу.


              В Debian там в конфиге по дефолту стоит 1 строка DEVICESCAN …, поэтому имеет смысл завести баг в smartmontools на тему DEVICESCAN, т.к. smartd сканирует nvme по аналогии с /dev/sd[a-z]\d+, а надо бы ему игнорировать символьные устройства и брать /dev/nvme\d+n\d+.

                +2
                Не надо устройства переименовывать. Там всё уже правильно названо.

                неправильно же, nvme0n1 не должно соответствовать nvme1 и наоборот!
                я проверил свои хосты — на одном тоже такую беду обнаружил.
                думаю, что надо заводить баг в ядерной багзиле.


                akrupa, займётесь или лучше мне?

                  +1
                  edo1h
                  Это будет долгая игра. Думаю, что баг будет иметь низкий приоритет и фикс выйдет в релиз не очень скоро.

                  Если займетесь, буду благодарен.
                    –1
                    nvme0n1 не должно соответствовать nvme1

                    nvme0/nvme1/… — это символьные устройства, почему они вообще отдают какую-то инфу smartmontools'у — вот это вопрос. Туда имеет смысл копать, по-моему.

            +1
            почему это не совпадает с /dev/nvme0n1 — это вопрос к авторам smartctl видимо
            А причём тут smartctl? Ведь названия устройствам назначает ядро, а то, что оно не может сопоставить символьное устройство с блочным — ну тут ничего не поделаешь
            +5
              0

              Так надо просто из бекапов восстановиться — вы сделали бекапы перед тем как производить какие то действия с массивом, правильно? Я например когда это обнаружил просто восстановил из бекапов

                +2
                Резервные копии конечно-же есть. Делаются автоматически, регулярно и на внешнее устройство. Но, тут обошлось даже без восстановления из резервных копий. Спасло то, что NVMe SSD заменяются на основе SMART атрибутов до фактического выхода из строя. Оставшийся в массиве «плохой» диск был способен проработать еще пару недель как минимум.
                Проблему заметили вовремя и перенесли с него данные на новый рабочий носитель в штатном порядке.
                0

                Вопрос не по теме: а что может произойти с таким накопителем кроме износа всех ячеек?

                  +1
                  Собственно износ и происходит. Есть, правда и второй вариант…
                  Эти SSD греются сильно… если на них плохо наклеить радиатор (или вообще не наклеить), то они перегреваются и могут выйти из строя раньше срока. Внешне выглядит как износ, только намного быстрее происходит.

                  На уровне юмора: массив из четырех накопителей по схеме Mirror0-Mirror1-Spare-RMA дает бесконечный TBW при постоянной ротации, если SSD стабильно не доживают до заявленного производителем TBW.
                    0
                    это из то-же серии, как с массивом из обычных жестких дисков-желательно брать из разных партий?
                      +1
                      Да… лучше из разных чтобы исключить вероятность брака в партии. Но NVMe на самом деле можно даже брать разных моделей если они примерно по скоростям и задержкам подходят. Это не так критично как с дисками. Разных производителей SSD пока не пробовали мешать.
                        0

                        ну если учесть, что проблемы с прошивками сейчас одна из основных причин выхода из строя, брать разных производителей в общем-то разумно.

                  0
                  Никогда не пользуйтесь аппаратными рейдами на проде!
                  Кейс: у вас сгорает контроллер, вы судорожно хватаете резервный а там залита новая прошивка, которая несовместима с версией массива, созданной на старой прошивке.
                  Разумеется что у производителя уже нет таких контроллеров а прошивку он давно дропнул.
                    +3

                    Автор и не говорил об аппаратном.
                    Проблема вообще не зависит от типа рэйда.

                      +3

                      Ой как интересно. Вот, допустим, у меня сервер Dell с PERC 330 (ребрендированный LSI). Вы говорите, что:
                      а) Я не могу купить ему замену.
                      б) Замена не будет понимать формат.


                      … удивительные вещи вы говорите.


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

                        0
                        Тоже скажу удивительную вещь — я как-то попал так с HP еще лет 6 назад, рейд упорно не заводился на сервере той же линейки с тем же рейд-контроллером (правда с другой прошивкой и, вроде бы, другой ревизией). Саппорт предлагал разные прошивки и откровенное шаманство типа поменяйте-ка кабеля, но т.к. надо было очень срочно до конца так ничего и не доковыряли, создали новый массив и восстановили все из бэкапов.

                        В общем, всякое бывает.
                        +1

                        На неделе умер HP SmartArray P410, воткнули вместо него 212, поехали дальше. Это не говоря уже о серьёзных СХД, где контроллеров обычно пара — что очень хорошо избавляет от судорог при выходе одного из строя ))

                          0
                          Тут на самом деле все от задач зависит. Аппаратные удобны для HDD, если задействовать кэш на запись, который либо в RAM с батарейкой хранится, либо на SLC SSD контроллера. Программный рейд в этом плане проигрывает, конечно можно задействовать и на программном кэши, через flashcache, но нескольких перезагрузок по питанию, вы поймете, что это плохая затея.
                          Про несовместимость — частично верно, когда умирает плата — приходится ждать, на этот случай если только под рукой иметь такой же контроллер или запасной сервер.

                          Но вот если все диски в системе — SSD, то имхо программный рейд — самое лучшее и надежное решение. Единственное надо правильно диски промаркировать на сервере, иначе после отвала — будете долго искать, какой из них дохлый, светодиодом они уже не посветят…
                            0
                            Не хочу вклиниваться в холивар, но личное мнение, — аппаратные рейд, это точка отказа, если в системе он только один. Их должно быть два, либо на замену, либо какой-нить multipath должен работать с двумя контроллерами.
                            Лично, в свое время попадал с аппаратным рейдом с кэшем и батарейкой. Не спорю он проработал много лет, но когда погорел сервер где он стоял, выяснилось что под шину PCI эти контроллеры уже не делают и даже если купить БУ контроллер, то в новой системе он не факт что заработает.
                            Слава богам кэш в контроллере использовался в режиме write through и данные на дисках были целостны. В итоге восстановил данные собрав массив RAID6 из слепков дисков через специальный софт для восстановления данных. На удивление легко и быстро получилось.

                            Так что, лично для себя я решил аппаратные рэйды не использовать, если в системе нет резервирования хотябы на нескольких независимых узлах.

                            В данный момент использую следующую конфигурацию:
                            1. Массив из 2х-3х NVMe Samsung SSD 970 EVO в зеркале. Если 3, то третий — для горячей замены.
                            2. Массив из много Samsung SSD 860 QVO 2TB (SATA) в RAID1/RAID 6.
                            3. Массив из много HGST Travelstar 7K1000 (SATA) тоже в RAID 6.

                            1. — используется для root fs, lvm-cache и метаданных lvm-thin
                            2. — используется для boot (маленькое зеркало в начале под GRUB) и как lvm-основное хранилище данных за кэшем (RAID 6).
                            3. — используется исключительно для резервного копирования.

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

                          Насколько мне известно по рассказам ментейнеров nvme подсистемы ядра, никто не обещал, что nvme1 и nvme1n1 будет одним и тем же устройством, просто так получилось. Все сломалось, когда в nvme завезли поддержку nvme multipath, и у неймспейса внезапно могло стать два контроллера, т.е. nvme1 и nvme2 обслуживают какой-нибудь nvme3n1. Т.е. предыдущая модель сломалась, а поддерживать старое поведение для устройств с одним путем никто не стал. Изменение было очень фрустрирующим, и были планы вообще развести устройства неймспейсов и контроллеров по разным номерам, т.е. если есть /dev/nvme1, то /dev/nvmе1n1 быть не может, и наоборот. Не знаю, завезли это, в апстрим, или так и осталось в планах.

                            +2

                            а где почитать? а то тут уже собрались багу заводить.


                            вообще такое поведение (nvme0 соответствует nvme1n1 и наоборот) выглядит очень запутывающим.


                            были планы вообще развести устройства неймспейсов и контроллеров по разным номерам

                            мне кажется, просто поменять nvme0 на (условно) nvmectrl0 — и дело с концом

                              0
                              Личное мнение, — в случае multipath было бы неплохо именовать Namespaces по имени любого (желательно первого обнаруженного) контроллера через который они доступны. Но, точно не как сейчас.
                                0
                                Как я понял, там сейчас другая модель: создается nvme subsystem, с каким-то номером, а дальше подсистеме соответствует один или несколько контроллеров, у которых есть неймспейсы, типа nvme14c33n1, т.е. подсистема -> номер контроллера -> номер неймспейса. Эти устройства внутри ядра слепляются через multipath в одно, которое уже видно в userspace, и называется как подсистема -> номер неймспейса, например, /dev/nvme14n1.
                              0
                              … форматируем, и в массивы добавляем уже разделы, вроде /dev/sda1.
                              У меня, наверное, неправильные пчёлы, но я собрал программную 6-ку не разбивая диски на разделы. Они у меня в массиве sda, sdb и т.д. 2 с половиной года полёт нормальный.
                              Может я что-то не правильно сделал? Правда диски обычные на ssd.
                                +1
                                Так тоже можно. Разделы там надо создавать если хочется сделать массив загрузочным. Или сделать одновременно зеркало (RAID1) и RAID6 на разных кусочках одного диска.
                                  0

                                  Ну это мягко говоря не по религии. Сломать кроме психики ничего не должно.

                                    0
                                    Ну это мягко говоря не по религии

                                    почему? как раз для таких случаев, кстати, сделали разбиение md-устройств на разделы.
                                    плюс этого подхода: проще заменять сбойный диск (не надо на подменном таблицу разделов создавать, просто добавить его в массив).
                                    минус: нельзя будет добавить диск если его размер на несколько секторов меньше (такое случается, если решили воткнуть диск другого производителя). в zfs об этом подумали: прозрачно для вас создаётся небольшой второй раздел в конце диска, "играясь" размером которого можно всё поправить.

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

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