Dotaz: Chyby na disku

[jan.rok]

Dobrý den,

rád bych poprosil o radu zkušenější:

Na serveru s RHEL8, s hardwarovým RAID řadičem mám mj. RAID5 pole s 3 HDD.

 lsblk
NAME                           MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT
sda                              8:0    0  558.9G  0 disk
└─sda1                           8:1    0  558.9G  0 part
  ├─rhel--raid1-max_maxp_spool 253:2    0      8G  0 lvm  /max/maxp/spool
  ├─rhel--raid1-IDSLOGS        253:3    0     32G  0 lvm  /IDSLOGS
  └─rhel--raid1-data1          253:4    0  518.9G  0 lvm  /data1
sdb                              8:16   0    1.7T  0 disk
├─sdb1                           8:17   0 1023.8M  0 part /boot/efi
├─sdb2                           8:18   0      2G  0 part /boot
├─sdb3                           8:19   0    1.6T  0 part
│ ├─rhel--raid5-root           253:0    0     32G  0 lvm  /
│ ├─rhel--raid5-swap           253:1    0     16G  0 lvm  [SWAP]
│ ├─rhel--raid5-home           253:5    0      2G  0 lvm  /home
│ ├─rhel--raid5-var            253:6    0     12G  0 lvm  /var
│ ├─rhel--raid5-tmp            253:7    0      4G  0 lvm  /tmp
│ ├─rhel--raid5-max            253:8    0     16G  0 lvm  /max
│ ├─rhel--raid5-max_maxp_homes 253:9    0     12G  0 lvm  /max/maxp/homes
│ ├─rhel--raid5-IDSDATA        253:10   0    120G  0 lvm  /IDSDATA
│ └─rhel--raid5-data2          253:11   0    1.4T  0 lvm  /data2
└─sdb4                           8:20   0   54.5G  0 part
  └─rhel--raid5-max_maxp_homes 253:9    0     12G  0 lvm  /max/maxp/homes

Při běžné kontrole /dev/sdb3 pomocí badblocks -s -v /dev/sdb3 jsem našel 32 vadných bloků. Provedl jsem badblock -svnf /dev/sdb3, kontrola našla ty stejné vadné bloky, ale ačkoliv jsem očekával opravu (nebo spíš označení jako nečitelné), tak další kontrola stále zobrazuje ty samé vadné bloky. Při práci s diskem zatím žádný problém s nečitelností dat nepozoruju (což může být jen náhoda), projevuje se to však při zálohování pomocí VEEAM Agent for Linux, které končí chybou při čtení disku.

Jaký by měl být další postup? Data mám samozřejmě odložená i jinde. RAID adaptér chyby nehlásí, SMART taky ne. Ideální by bylo vyměnit všechny disky v poli, ale to je až krajní možnost.

Díky. JR

---

---

Odpovědi

[X]

Tady mas nekolik rad. Nedelas to na zivem systemu? Zkus

e2fsck -fccky /dev/sdXX

No a konecne to muzes naformatovat. Souborovy system?

[jan.rok]

Je pravda, že zatím jsem to spouštěl na živém systému (odstávka není organizačně jednoduchá, ale v tomto případě bude stejně nutná, jinak to hrozí průšvihem).

Je tam ext4.

[AraxoN]

Z mojej skúsenosti, ak tam sú vadné sektory, zanedlho ich bude viac a potom ešte viac. Nemá zmysel to obchádzať cez badblocks, ale radšej si obstarať náhradný disk a vymeniť ho.

O ktorý disk sa jedná, by sa malo dať zistiť utilitou k danému HW RAID radiču, napr. megasasctl -e k radiču MegaRAID SAS a pod.

Radič by sa mohol dať zistiť napríklad takto:

lspci | grep -i raid
01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] (rev 02)

[jan.rok]

Když se na to dívám přes iLO5, tak všechny disky vypadají OK.

[AraxoN]

Okrem stavu by tá utilita výrobcu mala písať aj nejaké prevádzkové údaje k diskom (podobné SMART-u). Napr. výstup z jedného MegaRAID-u, kde nám odchádzal disk:

megasasctl -e
a0       ServeRAID M1015 SAS/SATA Controller encl:1 ldrv:1  batt:FAULT, module missing, pack missing, charge failed
a0d0      271GiB RAID 10  2x2  optimal
a0e64s0    136GiB  a0d0  online  
     write errors: corr:  0    delay:  0    rewrit:  0    tot/corr:  0    tot/uncorr:  0   
      read errors: corr:  0    delay:  0    reread:  0    tot/corr:  0    tot/uncorr:  0   
    verify errors: corr:  0    delay:  0    revrfy:  0    tot/corr:  0    tot/uncorr:  0   
a0e64s1    136GiB  a0d0  online  
     write errors: corr:  0    delay:  0    rewrit:  0    tot/corr:  0    tot/uncorr:  0   
      read errors: corr:  1Gi  delay:  0    reread:  0    tot/corr:  1Gi  tot/uncorr:  0   
    verify errors: corr:256Mi  delay:  0    revrfy:  0    tot/corr:256Mi  tot/uncorr:  0   
a0e64s2    136GiB  a0d0  online  
     write errors: corr:  0    delay:  0    rewrit:  0    tot/corr:  0    tot/uncorr:  0   
      read errors: corr:  2Gi  delay:  0    reread:  0    tot/corr:  2Gi  tot/uncorr:  0   
    verify errors: corr:  1Gi  delay:  0    revrfy:  0    tot/corr:  1Gi  tot/uncorr:  0   
a0e64s3    136GiB  a0d0  online  
     write errors: corr:  0    delay: 94    rewrit:  1    tot/corr:  0    tot/uncorr:  1
      read errors: corr:  0    delay: 10    reread:  8    tot/corr:  0    tot/uncorr:  8
    verify errors: corr:  0    delay:  0    revrfy:  8    tot/corr:  0    tot/uncorr:  8

V tomto prípade bol chybný disk č. 4 (a0e64s3), pretože mal uncorrected errors.

[Andrej]

Je tam ext4.

Tohle↑ tedy hrozí průšvihem jednoznačně. Časovaná bomba. V roce 2023 to nemá co dělat.

[Ja osobne]

Jedine ZFS alebo BTRFS?

[jan.rok]

Ale jo, to nerozporuju. Je to dané dodavatelem IS, 2018.

[X]

Zaridit odstavku a potrebujes novy sever s vyrazne modernejsi/stabilnejsi konfiguraci kam se to presype..

[Jendа]

Já potřebuju vysvětlit jak může „HW RAID“ vracet „vadné bloky“. To jsou jako bloky nečitelné na dvou discích ze tří? Protože když jsou nečitelné na jednom, tak od toho je to přece RAID, aby to vrátil z těch dalších (a pokud se to bude opakovat, tak si vyžádal toho vadného disku výměnu).

Potřebuješ vyrazit z těch fyzických disků SMART data. To se liší „HW RAID“ od „HW RAIDu“, takže hodně štěstí… Na jednom z nich snad v tom SMARTu budou vidět mrtvé sektory.

A pak nelze než doporučit postavit to znova s MD-RAIDem :) (nebo btrfs pokud jsi dobrodruh)

[Ja osobne]

ZFS pre Linux alebo rovno TrueNAS...

[Heretik 《小魔神》]

Badblocks false positives jsou časté při nedokonalém hardwaru. Běžné na USB3.

Podezíral bych HW RAID řadič nebo spíše kabely. Disky bych důkladně otestoval na jiné platformě. Je pravděpodobné, že samotné disky jsou v pořádku.

[Andrej]

Tak takového serveru bych se fakt bál. V jakém stavu jsou na něm data, to je ve hvězdách.

…s hardwarovým RAID řadičem…

Pozor, nic takového neexistuje. Je to chybný název, scam a pohádka. Takzvaný „hardwarový“ řadič má dvě „skvělé“ vlastnosti:

• Na AID1 bude vracet náhodně zničená data, když bude jedna z replik z jakéhokoliv důvodu zničená. Prokládané čtení vrátí tu platná data, tu zase neplatná, a nikdo nebude vědět, která jsou která.
• Na AID5 selhání kteréhokoliv jednoho disku zničí všechna data na všech discích, protože může nečekaně spustit resilvering a namíchat zničená data do distribuované parity i do datových bloků všude.

RAID se tomuhle↑ ve slušné společnosti neříká. Je to AID bez R.

Ideální by bylo vyměnit všechny disky v poli, ale to je až krajní možnost.

Bohužel existuje nesmyslná pověra, že se mají disky měnit najednou, že se mají kombinovat jenom disky podobného stáří a podobně. Máloco může být vzdálenější pravdě.

Takový nesmysl pak vede k potu a slzám — a kaskádám selhání. Když na starém RAID5 (neřkuli AID5) začne náročná oprava po náhradě disku, pravděpodobnost selhání dalšího disku je nepříjemně vysoká.

Proto je rozumné mít v RAID poli plánovanou rotaci disků. Jasně, zpočátku pole sestává z nových disků a je zdánlivě škoda je rotovat, ale takový už je život; buď chci dlouhodobý spolehlivý provoz bez náhlých dramatických událostí, nebo mám jiné priority…

Příklad rotace: Dejme tomu, že máme (skutečný) RAID (pozor, ne „hardwarový“ AID) s 8 disky. První dva roky se nechá běžet beze změn. Pak se každý kvartál vymění 1 disk, toho času nejstarší (nebo zpočátku jeden z nejstarších, dokud je ještě stáří některých disků stejné). Co tohle zajistí:

• Žádný disk není nikdy starší než 4 roky.
• Není nouze o nouzové náhradní disky; třeba ten, který byl vyřazený hned po dvou letech, může ještě jednoho dne zachraňovat svět.
• Nakonec to celé zkonverguje k rozdělení stáří disků od prvního do osmého kvartálu provozu — a díky tomu je i v případě výměny disků a různých dramatických selhání nižší pravděpodobnost, že přijde kaskáda selhání najednou.
• Proces výměny disků je známá rutina a v případné nouzové situaci (byť méně pravděpodobné než „obvykle“) je náprava rychlejší, s nižší pravděpodobností selhání lidského faktoru.
• Starosti, co s vadnými bloky a jestli a kdy, odpadnou, protože to do takové fáze zpravidla nedospěje.

Samozřejmě záleží na tom, jaké požadavky se na příslušný server kladou a kolik stojí (zbytečná a nečekaná a přesčasová) práce lidí v případě selhání ve srovnání s … koupí jednoho disku za kvartál. Bude tam značný nepoměr; zbytečná práce lidí je klidně o dva desítkové řády dražší.

├─sdb3                           8:19   0    1.6T  0 part
│ ├─rhel--raid5-root           253:0    0     32G  0 lvm  /
│ ├─rhel--raid5-swap           253:1    0     16G  0 lvm  [SWAP]
│ ├─rhel--raid5-home           253:5    0      2G  0 lvm  /home
│ ├─rhel--raid5-var            253:6    0     12G  0 lvm  /var
│ ├─rhel--raid5-tmp            253:7    0      4G  0 lvm  /tmp
│ ├─rhel--raid5-max            253:8    0     16G  0 lvm  /max
│ ├─rhel--raid5-max_maxp_homes 253:9    0     12G  0 lvm  /max/maxp/homes
│ ├─rhel--raid5-IDSDATA        253:10   0    120G  0 lvm  /IDSDATA
│ └─rhel--raid5-data2          253:11   0    1.4T  0 lvm  /data2

Tohle↑ je učiněná katstrofa. Zbytečné tříštění prostoru nedává nikdy smysl. Aby jeden proces nezabral druhému procesu celý disk, od toho jsou kvóty a podobné vymoženosti, které lze kdykoliv dynamicky upravit, trvale nebo dočasně, podle potřeby.

Co když bude /var jeden den potřebovat 13G místo 12G? S rozumným (ne)rozdělením diskového prostoru tohle není žádný problém. Upravím kvótu, uložím/vypočítám, co je potřeba, pak zase kvótu zredukuju. S touhle šíleností se z úplně běžné věci stává rocket science, zoufalství a hra na pacmana k tomu.

Jasně, že LVM dokáže (libovolně fragmentovaně) přidat k LV další bloky odněkud odjinud a v tom se pak dá nafouknout souborový systém — který rozhodně nemá být od volume managementu ani od RAIDu oddělený, leč u obsolete technooogií typu LVM bohužel je —, ale nechtěl bych něco takového podstupovat. Přesněji, v roce 2003 klidně jo, protože tenkrát bych musel. V roce 2023 už ne, protože … nemusím.

[pavele]

Zapomněl jsi připojit tu radu nebo odpověď na otázku, kterou čeká tazatel...

[jan.rok]

Tazatel moc možností nemá:

- iLO5 ukazuje, že disky jsou ok, přesto badblocks nachází vadné bloky

- utilita pro čtení SMART ukazuje, že je vše ok

- záloha pomocí VEEAM neběží, končí na chybě input/output, prostě něco nepřečte

K dispozici mám náhradní disk do pole. Nyní běží ruční kopie všeho někam pryč ze serveru. Následovat bude výměna prvního disku z RAIDu za náhradní, rebuild pole a následná kontrola pomocí badblocks. Tak budu pokračovat, dokud kontrola nedoběhne bez chyb.

Vše jen zintenzivní jedníní o dlouho odkládané výměně již starého serveru za jiný.

[Max]

Hloupý dotaz. SmartAraay řadiče jsou docela zabugovaný, aspoň podle changelogů a warningů, co mi od HPE chodí. Tj., flashuješ? Máš tam aktuální fw?
Zdar Max

[jan.rok]

Přiznávám, že asi víc jak rok starý. Ale chyba se objevila až teď.

[pavele]

No já nevím, chyba disku je přece běžná věc, tedy podle mě, proto RAID, zálohování atd.

Identifikuju vadný disk, vyměním, provedu rebuild a hotovo.

Nejsem proti výměně celého serveru, ale stejná situace přece může nastat i s novým serverem a novými disky a souborovým systémem "jsem_naprosto_špička".

Abych při každé chybě disku měnil server - nevím, nevím.

Vždy jsem identifikoval vadný disk, provedl výměnu a jelo se dál.

[Jendа]

Ano, a jemu to zjevně nefunguje - jednak mu chybu na disku vrací RAID (jak se to proboha může stát, to by musel být stejný sektor vadný na dvou discích současně; nebo takhle možná dává najevo že mu nevyšla parita? zkoušel ten blok přepsat?) a jednak nedokáže zjistit který disk je vadný (RAID mu neřekl diagnostiku jak k chybě došlo a disky se ve SMARTu tváří zdravě -- bych skoro čekal že to fakt je problém řadiče).

Já nechápu proč proboha lidi furt „HW RAIDy“ používají. Ještě bych to chápal u NVMe, ale u běžných disků? Tam fakt není bottleneck ve výkonu. Ještě tu teda někdo psal že je pro něj důležitá baterková writeback cache.

[Peter Golis]

Ono to môže byť aj tým, že do HW RAID poľa dal desktopový disk ktorý kľudne vráti blok núl namiesto chyby pri čítaní, a odmietne zapísať na poškodený blok disku. S.M.A.R.T z HW RAID poľa sa zvykne spracovávať HW radičom a bez špeciálnych nástrojov sa nie vždy dá prečítať z diskov cez bežný smartctl keďže sa propagujú LUNy a nie jednotivé disky.

Teda ak to nie je WinRAID, čo nevylučujem. Také obskúrnosti sa montovali aj do serverov, a občas do servera dal správca taký (ehm) externý radič.

Takže bez detailov (typ radiča, verzia FW radiča a iLO, report z nástroja na ovládanie radiča a podobne) to tu ostane na úrovni flame wars či je lepšie so šípkovou alebo s kyslou kapustou.

[jan.rok]

Je to HP ProLiant ML110 Gen10 s řadičem HPE Smart Array P408i-p SR Gen10, všechny disky jsou serverové hot-swapové HP EG000600JWJNP. Server byl dodán dodavatelem informačního systému, oni ho i spravovali po dobu záruky, která asi před 2 měsíci skončila. Od té doby se o to nikdo nestaral, až jsem se k tomu dostal já. Zjistil jsem nefunkční zálohování, zjišťoval co se děje, našel vadné bloky.

Výměna serveru kvůli vadnému disku je samozřejmě nesmysl, avšak výměna serveru je tak nějak v dlouhodobém plánu provozovatele. Proč bych se tomu měl bránit, že.

A opravdu je to tak, že zatím neznám způsob, jak zjistit, který konkrétní disk je v háji.

A proč někdo pořád používá HW RAID? No třeba zde to snad ani jinak nejde. Disky se po zasunutí do šachty připojí na backplane, který je připojen k HW RAID adaptéru. To bych musel backplane vypárat, dát do PCI-E slotu jiný řadič, nějak řešit napájení a připojení. Tak proto.

Jak jsem psal výše: po ruční zazálohování budu měnit disk po disku a kontrolovat. Buď vadný disk objevím, nebo to celé lehne.

Přesto díky všem za názory a napíšu, jak jsem dopadl.

[Peter Golis]

To sú pekné verzie softwéru a firmwéru (UEFI BIOS, iLO, FW radiču, FW diskov, ...), odporučil by som to skontrolovať aj s podporovaným OS.

Tie nástroje na správu RAID vedeli urobiť aj hĺbkovú diagnostiku diskov, a zablikať vadným diskom nech človek vie ktorý disk má vymeniť. Stránky HPE zvykli mať download aj pre Linux. Akurát neviem či to už nepresunuli do sekcie pre registrovaných zákazníkov.

Samotné iLO malo viacero licencií. Niektoré vedeli akurát tak vypnúť, resetnúť alebo zapnúť server (poprípade povedať že stroj nabehol), niektoré vedeli potvrdiť základnú funkčnosť zostavy (to ostatne aj LEDky na doske), niektoré vedeli poskytnúť rozšírené informácie aj s vynútením rozšírenej diagnostiky a niektoré vedeli na diaľku informovať autorizovaného servisáka o potrebe výmeny zlyhávajúceho komponentu ktorý naklusal a zazvonil na dvere firmy bez toho aby sa dopredu ohlásil.

PS: Aj na HW RAID radičoch sa dali vypropagovať jednotlivé disky priamo do OS. Buď sa radiť priamo prepol do módu PassThrough, alebo sa vo FW RAID radiča zmenilo nastavenie a vytvorili sa jednotlivé LUNy štýlom jeden na disk. Ale s týmto sa neodporúčam hrať, je tam riziko deštrukčnej operácie.

[dustin]

Jenom k tomu přehození na HBA - mám dobré zkušenosti s připojením HP Proliant klecí do HBA řadičů LSI, vždy ve verzi odpovídající konektoru na kleci (SAS92xx, SAS93xx). Řadiče za pár korun z ebaye. Obvykle fungují i ledky včetně rozsvícení LOCATE přes utilitky sas.

Hlavní starost je, aby z toho uměl server nabootovat.

[Max]

Já nemám problém s HW polem ani se sw polem. Pokud by jsi chtěl řešit migraci na něco jiného, tak stačí vyměnit jen řadič za nějaký HBA (nejlépe asi od LSI). Backplane je připojen standardním konektorem, takže opravdu stačí jen jiný řadič.
Každopádně to, co ty řešíš, se mi snad nikdy nestalo.
Zdar Max

[Michal]

Kdo ti nakecal, ze hw raid radice neexistuji?

[jan.rok]

Mám jeden nový náhradní disk.

Náhradní disk jsem zapojil místo disku1, rebuild, kontrola - se stejnými chybami.

Původní disk 1 jsem zapojil místo disku2, rebuild, kontrola - se stejnými chybami.

Původní disk 2 jsem zapojil místo disku3, rebuild, kontrola - se stejnými chybami.

Původní disk 3 jsem zapojil místo disku4, rebuild, kontrola - se stejnými chybami.

Ve všech případech po dokončení rebuildu ukazuje iLO5 i CLI utilita, že je vše OK, avšak badblocks stále vypisuje ty samé chyby.

Tak tedy nevím...

[X]

Jak presne vypada ten chybovy vystup? Porad to delas na zivo?

[jan.rok]

Zatím pořád naživo.

Pass completed, 48 bad blocks found (48/0/0 errors)

[X]

Muzes vysvetlit proc to porad delas stejne blbe? Hned na zacatku jsem psal jak to mas udelat.

[Jendа]

To je workaround, který filesystému řekne, aby nepoužíval nějaké bloky, ne? Osobně bych takový workaround (=mám na zařízení vadné bloky, nedokážu diagnostikovat proč a jenom čekám na to, až se objeví nějaké další a tentokrát třeba v nějakém důležitém souboru) na produkčním systému fakt nechtěl.

[Peter Golis]

Technicky môže byť tá chyba spôsobená chybou vo FW alebo nedokončeným zápisom ak bol počítač nekorektne vypnutý. Tam by force fsck mohol odhaliť chybu.

Ale dôležité dáta sa uchovávajú na FS ktorý má checksumy na metadáta a aj na dáta. A tak isto sa aj verzionovane uchovávajú v inej lokácii. Ak to tak nie je, tak sa dostane ku slovu Single Point Of Failure.

Ja by som odporučil update FW, rebuild tej mašiny s nejakým rozumným FS, a nahrať dôležité dáta naspäť.

[pavele]

Nešlo by spíš postupně vytahovat disky a ten vytažený disk zkontrolovat samostatně na badblocks třeba na jiném pc nebo jej připojit jako externí přes USB3 a zkontrolovat - aby se vyloučil vliv OS a hardwaru - kabely, řadič atd.?

Jak konkrétně spouštíš badblocks?

[jan.rok]

sudo badblocks -sv /dev/sdb

[Max]

Já vždy testoval pomocí -nvv, ale nikdy to nebylo 100%. Skutečné chyby mi pak objevil až destruktivní test "-wvv".
Ale badblocks už nepoužívám strašně dlouho, protože prostě nedestruktivně to není moc vypovídající, destruktivně to není ideální a v dnešní době fake bloků a dalších věcí těžko říci, co skutečně testuji (navíc už na spoustě místech stejně používám SSD). Aktuálně tedy spoléhám už jen na hlášky FS (scrub apod.) a S.M.A.R.T. info.

Na tebou popsanou situaci jsem ale nenarazil. Nezkoušel jsi se dívat do changelogu aktuálních firmware řadiče? Rok sice není dlouhá doba, ale občas se tam objeví nějaká zákeřnost. To samé platí pro samotné disky (vycházejí firmware i na ně).
V případě HPE doporučuji použít poslední SPP a poté ručně doaktualizovat konkrétní komponenty.
Zdar Max

[drnest]

Když měl disk vadný bloky, testoval jsem to pomocí badblocks -nsv /dev/sda. Tím jsem řadič donutil použít záložní sektory. Jak je to v případě, že je to volume z RAIDu, ale netuším.

[AraxoN]

V dmesg nie je nič?

[jan.rok]

Je tam toto:

 critical medium error, dev sdb, sector 3154816248 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[305571.041556] Buffer I/O error on dev sdb, logical block 394352031, async page read

Ale ani z toho nevidím, který disk je vadný. Zkusím ještě data vykopírovat a RAID postavit znovu. Třeba to při tom nové buildu vyhodí nějakou chybu.

[k3dAR]

jak nevidis? pise dev sdb, coz je predpokladam ten dev na co si pustil badblock no a "hdparm -I /dev/sdb" (velke i ne l) ci "smartctl -x /dev/sdb" ti rekne jeho SN ktere najdes na stitku disku...
(to sdb se samozrejme muze zmenit pri rebootu)

[jan.rok]

Příkazy mi řeknou toto:

# hdparm -I /dev/sdb

/dev/sdb:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ATA device, with non-removable media
Standards:
        Likely used: 1
Configuration:
        Logical         max     current
        cylinders       0       0
        heads           0       0
        sectors/track   0       0
        --
        Logical/Physical Sector size:           512 bytes
        device size with M = 1024*1024:           0 MBytes
        device size with M = 1000*1000:           0 MBytes
        cache/buffer size  = unknown
Capabilities:
        IORDY not likely
        Cannot perform double-word IO
        R/W multiple sector transfer: not supported
        DMA: not supported
        PIO: pio0

smartctl -x /dev/sdb
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.3.1.el8_4.x86_64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HPE
Product:              LOGICAL VOLUME
Revision:             2.65
Compliance:           SPC-3
User Capacity:        1,800,279,121,920 bytes [1.80 TB]
Logical block size:   512 bytes
Logical Unit id:      0x600508b1001cb4dd10e0db406dca8872
Serial number:        PFJHD0ARCCZ1HF
Device type:          disk
Local Time is:        Tue Aug 15 21:04:45 2023 CEST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported
Read Cache is:        Enabled
Writeback Cache is:   Disabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

Device does not support Self Test logging
Device does not support Background scan results logging

Z toho pořád nevidím, o jaký fyzický disk jde.

[AraxoN]

Z man smartctl:

              To look at disks behind HP Smart Array controllers, use syntax such as:
              smartctl -a -d cciss,0 /dev/cciss/c0d0    (cciss driver under Linux)
              smartctl -a -d cciss,0 /dev/sg2    (hpsa or hpahcisr drivers under Linux)

Aký driver to používa? (lspci -v)

[jan.rok]

01:00.7 RAID bus controller: Hewlett-Packard Company Device 193f (rev 01)
        DeviceName: Embedded Storage
        Subsystem: Hewlett Packard Enterprise Device 00e4
        Flags: bus master, fast devsel, latency 0, IRQ 255, NUMA node 0
        Memory at d9b9c000 (32-bit, non-prefetchable) [size=16K]
        Memory at d9b98000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [70] MSI-X: Enable- Count=4 Masked-
        Capabilities: [80] Express Legacy Endpoint, MSI 00
        Capabilities: [f0] Power Management version 3
        Capabilities: [100] Advanced Error Reporting

[AraxoN]

Divné... dole by malo byť, aký kernel driver to používa. Napr.:

01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3008 [Fury] (rev 02)
        Subsystem: IBM MegaRAID SAS-3 3008 [Fury]
        ...
        Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
        Kernel driver in use: megaraid_sas

alebo

08:00.0 Serial Attached SCSI controller: Adaptec Smart Storage PQI SAS (rev 01)
        Subsystem: Lenovo ThinkSystem RAID 5350-8i PCIe 12Gb Adapter
        ...
        Capabilities: [300] Secondary PCI Express
        Kernel driver in use: smartpqi

[jan.rok]

Omlouvám se, správně má být tohle:

b1:00.0 Serial Attached SCSI controller: Adaptec Smart Storage PQI SAS (rev 01)
        Subsystem: Hewlett-Packard Company Smart Array P408i-p SR Gen10
        Physical Slot: 1
        Flags: bus master, fast devsel, latency 0, IRQ 34, NUMA node 0
        Memory at f3800000 (64-bit, non-prefetchable) [size=32K]
        I/O ports at c000 [size=256]
        Capabilities: [80] Power Management version 3
        Capabilities: [b0] MSI-X: Enable+ Count=64 Masked-
        Capabilities: [c0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [300] Secondary PCI Express
        Kernel driver in use: smartpqi
        Kernel modules: smartpqi

[AraxoN]

Mal by byť do nejakej miery kompatibilný s cciss aj s hpsa: (zdroj)

       smartpqi is a SCSI driver for Microsemi Smart Family controllers.

   Supported ioctl() operations
       For compatibility with applications written for the cciss(4) and
       hpsa(4) drivers, many, but not all of the ioctl(2) operations
       supported by the hpsa driver are also supported by the smartpqi
       driver...

Takže by mohlo fungovať niečo z toho predošlého príspevku (smartctl -d cciss,...)

[jan.rok]

Tak např.

smartctl -a -d cciss,0 /dev/sdb
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.3.1.el8_4.x86_64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HP
Product:              EG000600JWJNP
Revision:             HPD3
Compliance:           SPC-4
User Capacity:        600,127,266,816 bytes [600 GB]
Logical block size:   512 bytes
Rotation Rate:        10500 rpm
Form Factor:          2.5 inches
Logical Unit id:      0x5000c500c9cc3333
Serial number:        WFJ38HBE
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Wed Aug 16 07:40:34 2023 CEST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     49 C
Drive Trip Temperature:        60 C

Manufactured in week 09 of year 2020
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  347
Specified load-unload count over device lifetime:  300000
Accumulated load-unload cycles:  1486
Elements in grown defect list: 0

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0      58832.195           0
write:         0        0         0         0          0       4851.599           0
verify:        0        0         0         0          0         17.751           0

Non-medium error count:     9378

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   27161                 - [-   -    -]
# 2  Background short  Completed                   -   27161                 - [-   -    -]

Long (extended) Self-test duration: 3300 seconds [55.0 minutes]

Takhle dokážu prohlédnout všechny disky, ale ani na jednom mi to žádnou chybu neukáže.

[AraxoN]

Tak to musí byť niečo vadné v tom radiči, v kábloch, alebo v backplane, ku ktorému sa pripájajú disky.

[Max]

Pochop, že /dev/sdb je logická voluma, co ten řadič vytvořil .
Zdar Max

[k3dAR]

jasne, uniklo mi ze jde o HW-RAID :)

[jan.rok]

Dlužím zde zprávu, jak to nakonec dopadlo:

Po zajištění dočasného náhradního řešení jsem aplikace přesunul jinam. Diskové pole jsem vytvořil znovu, disky jednotlivě otestoval jinde. Vše zformátoval a vrátil do původního stavu.

Při žádné z dalších kontrol jsem pak už žádnou chybu nezaznamenal:

- iLO5 ukazuje vše OK

- SMART ukazuje vše OK

- badblocks okazuje 0 chyb

- záloha celého serveru pomocí VEEAM běží