Comments 33
А вот почему smartctl выдает что-то осмысленное на /dev/nvme0 как будто это диск, и почему это не совпадает с /dev/nvme0n1 — это вопрос к авторам smartctl видимо.
Device: /dev/nvme2, Temperature 59 Celsius reached critical limit of 59 Celsius (Min/Max 33/80)
Собственно да, отсюда и растут ноги у подставы. Особенность работы smartctl с NVMe. В сочетании с особенностью ядра, которое назначает имена контроллерам и нэймспейсам абы-как.
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+".
Тут главное, — знать о проблеме, т.к. с настройками по-умолчанию можно ошибиться по-незнанию.
Не надо устройства переименовывать. Там всё уже правильно названо.
Вот что надо сделать со 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+.
Не надо устройства переименовывать. Там всё уже правильно названо.
неправильно же, nvme0n1 не должно соответствовать nvme1 и наоборот!
я проверил свои хосты — на одном тоже такую беду обнаружил.
думаю, что надо заводить баг в ядерной багзиле.
akrupa, займётесь или лучше мне?
Это будет долгая игра. Думаю, что баг будет иметь низкий приоритет и фикс выйдет в релиз не очень скоро.
Если займетесь, буду благодарен.
nvme0n1 не должно соответствовать nvme1
nvme0/nvme1/… — это символьные устройства, почему они вообще отдают какую-то инфу smartmontools'у — вот это вопрос. Туда имеет смысл копать, по-моему.
почему это не совпадает с /dev/nvme0n1 — это вопрос к авторам smartctl видимоА причём тут smartctl? Ведь названия устройствам назначает ядро, а то, что оно не может сопоставить символьное устройство с блочным — ну тут ничего не поделаешь
Так надо просто из бекапов восстановиться — вы сделали бекапы перед тем как производить какие то действия с массивом, правильно? Я например когда это обнаружил просто восстановил из бекапов
Проблему заметили вовремя и перенесли с него данные на новый рабочий носитель в штатном порядке.
Вопрос не по теме: а что может произойти с таким накопителем кроме износа всех ячеек?
Эти SSD греются сильно… если на них плохо наклеить радиатор (или вообще не наклеить), то они перегреваются и могут выйти из строя раньше срока. Внешне выглядит как износ, только намного быстрее происходит.
На уровне юмора: массив из четырех накопителей по схеме Mirror0-Mirror1-Spare-RMA дает бесконечный TBW при постоянной ротации, если SSD стабильно не доживают до заявленного производителем TBW.
Кейс: у вас сгорает контроллер, вы судорожно хватаете резервный а там залита новая прошивка, которая несовместима с версией массива, созданной на старой прошивке.
Разумеется что у производителя уже нет таких контроллеров а прошивку он давно дропнул.
Автор и не говорил об аппаратном.
Проблема вообще не зависит от типа рэйда.
Ой как интересно. Вот, допустим, у меня сервер Dell с PERC 330 (ребрендированный LSI). Вы говорите, что:
а) Я не могу купить ему замену.
б) Замена не будет понимать формат.
… удивительные вещи вы говорите.
Не то, чтобы я был большой фанат проприетарщины, но надо различать сервера с поддержкой и гарантиями совместимости компонент от вендора и сервера в стиле "собрали сами из того, что в сусеках завалялось".
На неделе умер HP SmartArray P410, воткнули вместо него 212, поехали дальше. Это не говоря уже о серьёзных СХД, где контроллеров обычно пара — что очень хорошо избавляет от судорог при выходе одного из строя ))
Лично, в свое время попадал с аппаратным рейдом с кэшем и батарейкой. Не спорю он проработал много лет, но когда погорел сервер где он стоял, выяснилось что под шину 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. — используется исключительно для резервного копирования.
Оно вроде бы переживает перезагрузки по питанию нормально, но это было всего пару раз. Обычно все это живет годами не выключаясь с резервным питанием, и большинство носителей меняется на горячую.
Насколько мне известно по рассказам ментейнеров nvme подсистемы ядра, никто не обещал, что nvme1 и nvme1n1 будет одним и тем же устройством, просто так получилось. Все сломалось, когда в nvme завезли поддержку nvme multipath, и у неймспейса внезапно могло стать два контроллера, т.е. nvme1 и nvme2 обслуживают какой-нибудь nvme3n1. Т.е. предыдущая модель сломалась, а поддерживать старое поведение для устройств с одним путем никто не стал. Изменение было очень фрустрирующим, и были планы вообще развести устройства неймспейсов и контроллеров по разным номерам, т.е. если есть /dev/nvme1, то /dev/nvmе1n1 быть не может, и наоборот. Не знаю, завезли это, в апстрим, или так и осталось в планах.
а где почитать? а то тут уже собрались багу заводить.
вообще такое поведение (nvme0 соответствует nvme1n1 и наоборот) выглядит очень запутывающим.
были планы вообще развести устройства неймспейсов и контроллеров по разным номерам
мне кажется, просто поменять nvme0 на (условно) nvmectrl0 — и дело с концом
Ну это мягко говоря не по религии. Сломать кроме психики ничего не должно.
Ну это мягко говоря не по религии
почему? как раз для таких случаев, кстати, сделали разбиение md-устройств на разделы.
плюс этого подхода: проще заменять сбойный диск (не надо на подменном таблицу разделов создавать, просто добавить его в массив).
минус: нельзя будет добавить диск если его размер на несколько секторов меньше (такое случается, если решили воткнуть диск другого производителя). в zfs об этом подумали: прозрачно для вас создаётся небольшой второй раздел в конце диска, "играясь" размером которого можно всё поправить.
Подстава с NVMe на Линуксе