zfs szerint hibás disk, de a Seagate teszt szerint minden ok nincs bad sector

Linux-kezdő

Sziasztok!

Hátha valaki már találkozott ezzel az esettel.

A hétvégén szokás szerint elindult a havi scrub a pool-okon. Mielőtt befejezte volna az egyik diskre jelezte, hogy UNAV. Spare disk be, resilvering ok!
Miután kiszedtük a disket megnéztük, hogy valóban hibás-e.
Seagate lemezről lévén szó a SeagateTest programot használtuk, és meglepődtünk, mert a program kimeneteléből az derült ki, hogy a disk hibátlan.
Egy másik programmal HDD Sentinellel is teszteltük, amely program úgyszintén 100% jó kondicióba találta a lemezt.

De mégis akkor ez hogy is van?

Részletek logokból:

dmesg

end_request: I/O error, dev sdu, sector 3364781054
end_request: I/O error, dev sdu, sector 3371169922
end_request: I/O error, dev sdu, sector 3411735321
end_request: I/O error, dev sdu, sector 3385593576
end_request: I/O error, dev sdu, sector 3361964963
end_request: I/O error, dev sdu, sector 2214880589

daemon.log | grep zed

Feb 13 19:50:17 stor zed: eid=98 class=vdev.unknown pool=stor
Feb 14 12:08:39 stor zed: eid=99 class=scrub.finish pool=stor
Feb 14 12:08:39 stor zed: error: scrub.finish-notify.sh: eid=99: "mail" not installed
Feb 14 16:01:26 stor zed: eid=100 class=statechange
Feb 14 16:01:26 stor zed: eid=101 class=vdev.spare pool=stor
Feb 14 16:01:27 stor zed: eid=102 class=resilver.start pool=stor
Feb 14 16:01:30 stor zed: eid=103 class=config.sync pool=stor
Feb 16 22:16:44 stor zed: eid=104 class=resilver.finish pool=stor
Feb 16 22:16:44 stor zed: error: resilver.finish-notify.sh: eid=104: "mail" not installed
Feb 17 02:50:43 stor zed: eid=105 class=vdev.remove pool=stor
Feb 17 02:50:43 stor zed: eid=106 class=config.sync pool=stor

zpool event -v

Feb 13 2018 19:50:17.614708162 ereport.fs.zfs.vdev.unknown
class = "ereport.fs.zfs.vdev.unknown"
ena = 0xd197461403b02401
detector = (embedded nvlist)
version = 0x0
scheme = "zfs"
pool = 0x83a3068842936262
vdev = 0xaf2e711cd62f34cb
(end detector)
pool = "stor"
pool_guid = 0x83a3068842936262
pool_context = 0x0
pool_failmode = "wait"
vdev_guid = 0xaf2e711cd62f34cb
vdev_type = "disk"
vdev_path = "/dev/disk/by-id/ata-ST4000NM0033-9ZM170_Z1ZAN5ME-part1"
vdev_ashift = 0x9
vdev_complete_ts = 0x6edd194327ae73
vdev_delta_ts = 0x9567
vdev_read_errors = 0x0
vdev_write_errors = 0x0
vdev_cksum_errors = 0x0
parent_guid = 0x752b30c8257f1091
parent_type = "raidz"
vdev_spare_paths = "/dev/disk/by-id/ata-ST4000NM0033-9ZM170_Z1ZAN5QP-part1"
vdev_spare_guids = 0x14d4be9d46c0e1a9
prev_state = 0x1
time = 0x5a833369 0x24a3b3c2
eid = 0x62

Milyen okai lehetnek a zfs -nek egy disket UNAV -nak jelőlni még?

  • 1861 megtekintés

A SMART adatokkal biztos, hogy minden rendben? (az egy dolog, hogy nincs hibás szektor)
Simán lehet tápellátási gondja a HDD-nek, ami alapvetően nem okoz kondíció csökkenést, viszont a zfs kidobhatja.

---
Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.

Én inkább a zfs-nek hinnék: https://blogs.oracle.com/bonwick/zfs-end-to-end-data-integrity
Bár a Te esetedben már a kernel is hibát észlelt.
Azt javasolnám, hogy smartctl-el írass ki mindent. Az általad használt tool-ok nem tudom mi alapján gondolják jónak. Lehetséges, hogy azóta remappelte a hibás szektorokat és ezt elfogadják jónak stb...

( szilas | 2018. 02. 20., k – 15:29 )

Há mondjuk ez a széria nem a megbízhatóságáról híres. De.... velem már fordult elő, hogy a SMART szerint minden ok volt, de egy badbloks szépen kidobott vagy 5 bad szektort.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( mauzi v | 2018. 02. 20., k – 21:01 )

Alapvetés: a SMART-ra sose vegyél mérget, gyakran látunk olyan fél- vagy teljesen holt diszkeket, amik a SMART szerint hibátlanok.

Egy korábban hibás, akár adatvesztést is elszenvedő diszk többféleképpen "meg tud javulni":

- a diszken volt egy hibás szektor, de a firmware időközben reallokálta a hibás szektort. Ilyenkor a diszk aktuálisan tényleg "hibátlan". (A reallokálás tényét általában látod a SMART-ban, pl. Reallocated Sector Count)

- a diszken volt olvashatatlan adat, de a felülírását követően már olvasható. Ilyenkor nem történik reallokálás, a diszk "csendben meggyógyul". Esetleg valamilyen SMART értékből következtethetsz rá (Uncorrected Error Count, Reported Uncorrected Errors, stb.)

- az olvasás nem sikerült az erre megengedett timeout időn belül. Ez nem feltétlenül reprodukálható, ha a jel/zaj aránya a határérték közelében mozog. A diszk alapból tud, és szokott is újrapróbálkozni, amit általában nem veszel észre, csak ha már a sokadik próbálkozás után belefut a timeoutba.

( denke v | 2018. 02. 20., k – 23:07 )

Szia!

Szimplan es egyszeruen az tortent hogy a kernel elvesztette a merevlemezzel a kapcsolatot. Ez sok kulombozo okbol is megtortenhet, a lehetosegeket az altalam tapasztalt valoszinusegi sorrendben irom le:

-Hibas sata kabel, vagy koszos / oxidalt erintkezo a kabelen vagy a csatlakozon amire a kabelt dugod (alaplap / vezerlo kartya / merevlemez)
-Alaplapi / dedikalt sata vezerlo hiba
-Merevlemez kontroller hiba (ez nem kerul bele a smartba)
-Kernel hiba az adott vezerlo drivereben (ilyenkor szokott latszodni a dmesgben valami "kernel Oops" ami gyakorlatilag egy idoben elkapott kernel panik)
-tapellatasi hiba
-manualis beavatkozas, pl hdparm -Y (nagy Y)

En a helyedben megneznem a smartban az "UDMA CRC error count" nevu sort, ha ez nem 0 vagy nagyon alacsony, akkor az elso 3 valamelyike, altalaban kabel csere megoldja.

Ha fontosak az adataid akkor celszeru heterogen rendszert kialakitani:
-Ne ugyanattol a gyartotol
-Ne ugyanabbol a szeriabol
-ne ugyanolyan tipusu
-ne ugyanolyan koru
... merevlemezeket hasznalj mindenhol, igy meg tudod elozni a "correlated failure" jelenseget (nem egyszerre doglik majd meg minden egy hibas / eloregedett) hdd batch eseten

Nagyon elorelato a zfs scrub futtatasa nemcsak a bitrot javitasa miatt, de azert is mert igy "megrangatod" a hddket, es nem akkor fog elromlani a tobbi amikor egy kiesett hdd-t probal potolni a raid tomb es ezert megnovekszik a seek terheles a tobbin (1-2 honapja lattam ilyet egy ugyfelnel, kiesett disc potlasa alatt megdoglott meg 2 a tombben, seagate discek voltak ... szerencsere volt mentese)

( herka v | 2018. 02. 21., sze – 06:57 )

Bios/firmware up to date?
Nekem volt már olyan esetem,amikor a support nem a diszket cserélte,hanem úgy kezdte, hogy fw update. Onnantól megszűnt a hiba.
És én sem a sentinelnek hinnék.

Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

( mauser1 v | 2018. 02. 21., sze – 17:14 )

Köszönöm, az ötleteket átnézem.

( mauser1 v | 2018. 02. 21., sze – 19:17 )

Még egy apróság. Átgondolva a dolgot.
Jelenleg havonta egy időben indult a scrub a szolgáltatást végző storage-on , és a backupon is.
Inkább átkonfiguráltam, hogy legalább két hét különbséggel fussanak, ha esetleg mind kéttőn beüt valami hasonló eset, legyen idő helyreállítani vagy ezt vagy azt.