Beelink ME Mini NVMe-status i ZimaOS: Gränssnittsmappning kontra diskhälsa

Slutsats: Om RAID fungerar men ZimaOS säger att NVMe-diskarna saknas bör du misstänka platsmappningen innan diskfel

På flera installationer av Beelink ME Mini förblev RAID 0/5-lagringen läs- och skrivbar via SMB, medan instrumentpanelen visade saknade NVMe-diskar eller felaktig information om ledigt utrymme. Det mönstret innebär att Linux och RAID-lagret redan kan se enheterna. Det felaktiga lagret är ZimaOS fysiska platsmappning och användargränssnitt.

ZimaOS Storage visar en RAID5-pool där NVMe-diskar rapporteras som saknade på en Beelink ME Mini — Poolen förblev åtkomlig, men ZimaOS visade fyra NVMe-platser som saknade, trots att den underliggande RAID-enheten fungerade.

ZimaOS Storage visar en RAID0-pool där NVMe-medlemmar saknas i den visuella platskartan — En andra pool visade samma avvikelse: användbar RAID-lagring under ytan, men felaktig visning av fysiska diskar i instrumentpanelen.

Kontrollera först att NVMe och RAID är felfria under gränssnittet

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
lspci | grep -i "Non-Volatile"
cat /proc/mdstat
df -h

Om RAID-enheten är monterad, SMB fungerar och de förväntade NVMe-enheterna visas i lspci/lsblk, bygg inte om arrayen bara för att korrigera instrumentpanelen. Aktuella lagringsvyer i ZimaOS är avsedda att visa diskhälsa, kapacitet samt läs- och skrivinformation när mappningen är korrekt.

ZimaOS lagringsstatus visar det förväntade slutresultatet.

NVMe-mappning använder PCI-adresser, inte lsblk HCTL

ZimaOS-terminal där lsblk -o hctl endast returnerar HCTL-rubriken för NVMe-enheter — Denna misslyckade diagnostik illustrerar ett vanligt misstag: HCTL är användbart för SCSI-/SATA-liknande enheter, medan NVMe-mappning kräver PCI-adresser i stället.

Den gamla korrigeringen för hårdvara som inte kommer från Zima använde lspci för NVMe. lsblk -o hctl är SATA/SCSI-grenen och kan ge inget användbart resultat för NVMe. Denna skillnad löste förvirringen i tråden.

Den historiska korrigeringen av local-storage.conf

IceWhales lösning för hårdvara som inte kommer från Zima /etc/casaos/local-storage.conf och uppdaterade NVME mappning som matchar PCI-adresserna som exponeras av lspci, följt av:

systemctl restart zimaos-local-storage

Senare användare upptäckte att det faktiska parserbeteendet i deras versioner krävde blankstegsseparerade adresser i stället för det kommaseparerade exempel som ursprungligen publicerades. Eftersom detta är en gammal lågnivålösning bör du säkerhetskopiera konfigurationen och först föredra det aktuella ZimaOS-beteendet innan du redigerar den manuellt.

mappningen av diskar som inte är från Zima bevarar den historiska proceduren.

Så här ser en korrigerad NVMe-vy ut

ZimaOS RAID5-pool med tre TEAMGROUP-NVMe-SSD:er som visar hälsa, temperaturer och noll procent användning — En senare Beelink-konfiguration visade det avsedda resultatet: individuella NVMe-modeller, kapacitet och temperaturer var synliga i lagringsgränssnittet.

ZimaOS RAID5-pool med tre Crucial 2 TB-NVMe-SSD:er samt information om hälsa och temperatur — En annan korrigerad konfiguration visade NVMe-modellnamn, användning och temperaturer i stället för platshållarkort för saknade diskar.

ZimaOS RAID5-lagringsskärm som visar tre Crucial 4 TB-NVMe-SSD:er korrekt identifierade — En fungerande platsmappning med tre 4 TB-NVMe-enheter visade att problemet gällde användargränssnittets mappning, inte RAID-funktionaliteten.

ZimaOS-lagring som visar sex saknade NVMe-diskar i instrumentpanelen innan NVMe-PCI-mappningen korrigerades — Alla sex NVMe-platser visades som saknade trots att poolen fanns, vilket bekräftade att den visuella platskonfigurationen var felaktig.

ZimaOS RAID5-pool med sex Crucial-NVMe-SSD:er som visas korrekt efter att PCI-adressmappningen uppdaterats — Efter att NVMe-PCI-adressmappningen korrigerats visades alla sex SSD:er med modell-, kapacitets- och temperaturdata.

När mappningen är korrekt kan instrumentpanelen visa varje SSD-modell, storlek, temperatur och användning i stället för platshållarkort för saknade diskar. Åtgärden ändrar hur ZimaOS kopplar fysiska PCI-enheter till visuella platser; den reparerar inte filsystemdata.

Så kontrollerar du NVMe-hälsan oberoende av användargränssnittet

nvme list
nvme smart-log /dev/nvme0
smartctl -a /dev/nvme0

nvme-cli-hälsokontroller tillhandahåller Linux standardverktyg för NVMe. Använd dem när instrumentpanelen verkar felaktig men du fortfarande behöver bevis på enhetens hälsa.

När du inte bör redigera platsmappningen

Om NVMe-enheten saknas i lspci och lsblk, du har inte enbart ett problem med användargränssnittet. Kontrollera först BIOS, att enheterna sitter ordentligt, platsens protokoll, strömförsörjning och maskinvarukompatibilitet. En ändring av platskartan kan inte få en fysiskt oupptäckt enhet att visas.

ZimaCube 2-lagring och RAID-återställning tillhandahåller säkrare referensarkitekturer.

Vanliga frågor

Varför fungerar min Beelink-RAID när ZimaOS visar saknade diskar?

Linux kan montera RAID-arrayen även om ZimaOS visuella platskarta inte stämmer överens med Beelinks PCI-topologi.

Bör jag återskapa RAID-arrayen för att åtgärda saknade NVMe-kort?

Nej. Om data går att läsa och arrayen är felfri bör du korrigera eller rapportera gränssnittsmappningen i stället för att förstöra en fungerande array.

Varför visar lsblk -o hctl ingenting?

NVMe-enheter är PCIe-enheter och den gamla lösningen använde lspci-adresser. HCTL är mer relevant för enhetsmappning i SCSI-/SATA-stil.

Kan jag fortfarande använda nvme-cli om ZimaOS-gränssnittet visar fel?

Ja, om enheten är synlig för Linux. nvme smart-log kan tillhandahålla information om hälsa, temperatur och felräknare oberoende av instrumentpanelen.

Är redigering av local-storage.conf fortfarande det rekommenderade första steget?

Nej. Det är en historisk lösning för hårdvara som inte kommer från Zima. Testa den aktuella versionen först och säkerhetskopiera konfigurationen innan du gör manuella ändringar.