zpool failmode állapota

Linux-kezdő

Sziasztok.
Ha esetlegesen a zpool "failmode-ban" megadott értékre vált akkor azt hogy tudom megnézni, van-e rá valami parancs?

zpool Properties
http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r00/index.html

Bekövetkezik a katasztrófa és wait ba kapcsol.
Ha jól gondolom akkor az adott pooln belül, nem tudok filet létrehozni, de olvasni igen.
De le lehet ezt valahogy kérdezni?
zpool get failmode status tesztpool? vagy valami.
Ha több pool is van a gépen, ilyen esetben a többi pool használható marad?

Mi előtt teljesen hülyének néztek:
zpool status:
http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r74/index.html

De itt nem írja , hogy hogy jelzi a ha a pool wait-ba kapcsol.

( Szenti v | 2017. 01. 29., v – 18:43 )

A failmode egy property, tehát így tudod lekérdezni: zfs get failmode POOLNAME.

A zpool status mit ír a kérdéses poolra?

Kösz, ez igy rendben is van: wait, continue vagy panic ad majd vissza.
A kérdésem az, hogy honnan tudom meg, hogy mikor van a zpool ilyen állapotban.
Szerencsére nem volt ilyen eset vagyis jobban mondva van egy hiba jelenség ami mögött ezt sejtem De nem tudom hogy mire kell esetleg figyelni.
Mit kell a kérdeznem a rendszertől, hogy azt lássam:
pld: zpool poolname is wait mode .

A hiba jelenség abból áll, hogy erről a zpoolrol zvol diskek iscsi val kiajánlva szerverekre.
Es egyik pillanatról a másikra ez megszakad a kapcsolat. Jobban mondva kb 5 perc alatt zajlik le az esemény, de ez ugye attól is függ, hogy mikor akarják használják a iscsi-s disket a cliensek.:
Log:
Az open iscsit -d 8 al inditom már egy ideje(debug level 8)
...
Jan 24 09:16:51 node06 kernel: [664190.018113] connection1:0: ping timeout of 5 secs
expired, recv timeout 5, last rx 4460935500, last ping 4460936752, now 4460938004
Jan 24 09:16:51 node06 kernel: [664190.018267] connection1:0: detected conn error (1011)
Jan 24 09:16:51 node06 iscsid: Kernel reported iSCSI connection 6:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jan 24 09:16:51 node06 iscsid: Kernel reported iSCSI connection 3:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jan 24 09:16:51 node06 iscsid: Kernel reported iSCSI connection 7:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jan 24 09:16:51 node06 iscsid: Kernel reported iSCSI connection 10:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jan 24 09:16:51 node06 iscsid: Kernel reported iSCSI connection 1:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jan 24 09:16:57 node06 kernel: [664196.390344] sd 7:0:0:3: rejecting I/O to offline device
Jan 24 09:16:57 node06 kernel: [664196.390706] sd 7:0:0:3: rejecting I/O to offline device
....

...
cat syslog20170124 | grep "Jan 24 09:1" | grep pdu
Jan 24 09:11:51 node06 kernel: [663890.042456] connection4:0: pdu (op 0x1 itt
0x10000025) rejected. Reason code 0x7
Jan 24 09:11:52 node06 kernel: [663891.017049] connection7:0: pdu (op 0x1 itt 0xf)
rejected. Reason code 0x7
Jan 24 09:12:11 node06 kernel: [663910.040787] connection4:0: pdu (op 0x1 itt
0x10000051) rejected. Reason code 0x7
Jan 24 09:12:12 node06 kernel: [663911.016961] connection7:0: pdu (op 0x1 itt 0x69)
rejected. Reason code 0x7
Jan 24 09:12:27 node06 kernel: [663926.120615] connection10:0: pdu (op 0x1 itt
0x1000004f) rejected. Reason code 0x7
.....
Egyenlőre ez a probléma csak a storage ujrainditásával orvosolható

log a cliensről mikor ujraindul a storage:
.....
Jan 24 09:17:05 node06 kernel: [664204.271696] sd 7:0:0:3: rejecting I/O to offline device
Jan 24 09:17:05 node06 kernel: [664204.271795] sd 7:0:0:3: rejecting I/O to offline device
Jan 24 09:17:15 node06 kernel: [664214.271783] sd 7:0:0:3: rejecting I/O to offline device
Jan 24 09:17:19 node06 kernel: [664218.384414] sd 10:0:0:11: rejecting I/O to offline
device
Jan 24 09:17:24 node06 iscsid: connect to 10.101.11.11:3260 failed (No route to host)
Jan 24 09:17:24 node06 iscsid: connect to 10.101.11.11:3260 failed (No route to host)
Jan 24 09:17:24 node06 iscsid: connect to 10.101.11.11:3260 failed (No route to host)
.....
Ebből arra következtetek, hogy nem hálózati a probléma.
Jumbo frame van végig az iscsin (teszt is ok :szerverről ping -M do -s 8972 10.101.11.11
+ az storage ujrainditása előtt az iscsiadm,ha ujra loginlok az ok, de viszont a disk , nem jelenik meg a /dev/disk/by-path -ben

A storage ujrainditása után viszont minden helyre áll.

És ebből következtettek arra hogy a zfs a hibás. Mintha ro-ba lenne a pool, de természetesen status ra mindent ok!

Ha legközelebb előfordul, már van stratégiám, hogy mit fogok letesztelni.pld: Írás a poolokban
jumbo ujra tesztelése, másik poolbol iscsi login másik szerverre ......
És nagyon jó lenne megtudni a pool esetlegesen wwait-ben van -e ??
Ha igen akkor esetlegesen elmerném sütni a zpool cleart.

Hát ez az elgondolás se tünik okésnak.

Itthon, lvm es "diskeket" adtam ki tgt -vel, majd read onlyba kapcsoltam (lvchange -pr iscsi/tesztiscsi), közben nyomtam neki a cliensen egy másolást, ahogy átcsaptam read only-ba.

[v jan 29 21:16:37 2017] XFS (sdd): metadata I/O error: block 0x301062 ("xlog_iodone") error 61 numblks 64
[v jan 29 21:16:37 2017] XFS (sdd): xfs_do_force_shutdown(0x2) called from line 1172 of file /build/linux-35gxh9/linux-3.16.36/fs/xfs/xfs_log.c. Return address = 0xffffffffa0283dfe
[v jan 29 21:17:07 2017] XFS (sdd): xfs_log_force: error 5 returned.
[v jan 29 21:17:37 2017] XFS (sdd): xfs_log_force: error 5 returned.

iscsi val semmi gond :(

de ha elcsapom alola a hálozatot:
connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4297706808, last ping 4297708060, now 4297709312
[v jan 29 21:37:18 2017] connection2:0: detected conn error (1011)

A hibaüzenettel magával, amit írt, foglalkoztál?

Erre gondolok:
Jan 24 09:17:24 node06 iscsid: connect to 10.101.11.11:3260 failed (No route to host)

Próbáltad pingelni a 10.101.11.11 -et?
Elérted?


Ha ez az a node06, amire gondolok, akkor gyanús, hogy 10.101.11.11-en nem fog semmit se elérni.
Olyan hálózat... nem mondom, hogy nincs is. de volt amikor még nem volt :D

Nem lehet, hogy amikor az iscsi scan-t (discovery) csináltad, a tpg behirdetett több tp-t is, de ezek között van olyan (is), amelyik path-on nincs meg az összeköttetésed?

Multipath-od be van konfigurálva?
Ameddig nincs, azt esetleg megpróbáltad, hogy kézzel override-olni azt amit az open-iscsi discovery-zik, azt fixen rá-erőszakolni, hogy ne akarjon multipath-kodni (ameddig nincs a multipath-od is rendesen bekonfigurálva), hanem csak 1 fix path-on menjen, de azon rendesen?

Semmi jelét nem látni amúgy a logokból zfs vagy iscsi hibának. A logok connectivity error-ra utalnak.

Ha a logok connectivity error-t mutatnak, akkor kár a zfs-nél, vagy iscsi-nál keresni a hibát.

BTW.: Mire gondolsz az alatt, hogy a jumbo újratesztelése?
ping -s 8900 -M do 10.101.11.11 ?

Szia, foglalkoztam természetesen, de ez a log bejegyzés, épp akkor kezdett el beírodni, mikor a storegot "resetelük", újrainditottuk. Ezért, gondoltam azt, hogy nem hálózati kapcsolat a probléma, mert megváltozik a logok bejegyzése:
Jan 24 09:17:19 node06 kernel: [664218.384414] sd 10:0:0:11: rejecting I/O to offline
device ->> ujrainditás (kb 10 perc) és ekkor már: node06 iscsid: connect to 10.101.11.11:3260 failed (No route to host).
.
Amit vizsgáltunk a storage ujraiditása előtt:
zpool status ok minden ONLINE számolok 0 0 0.
zpool-okba: rpool , 00 , 01 file létrehozás, beleírás, olvasás. mind sikeres volt.
Storageon iostat -eEn : (diskek) Nem láttunk hibát.
Ping , ok!
Egy "kulso noderol" iscsi discovery ami sikeres volt, majd iscsiadm login egy 00 poolbol kiajánlott disk(gabi), a login baromi lassan,de Succesfull lett, de a disk az ls-al /dev/disk/by-path -ben nem jelent meg, ugyan ez az o1 poolbol(móka) kiajánlott disk esetén is baromi lassan Sussesfull, de a disk sehol.Természetesen ezt elő teszteltünk, mikor nincs probléma, a login gyors , és a diskek is a helyükön voltak.

Teszt az NFS-re:
Sajatgépről ugyan arról a storage interfaceről amelyeken a külső node-n próbáltuk a iscsit, mount sikeres, file létrehozás, írás olvasás sikeres. unmount sikeres.

Ezekután következtetünk arra, hogy az iscsi deamon a ludas a dologban.

Multipath-ről még nem hallotam, nem igazán kerestem a konfigját se.
Lehet el kéne osztani a 10.101.11.11 és a 10.100.11.11. utvonal közt a diskeket? Az ip-k kamuk, de szerintem érted mire gondolok!!
Még egy nagy kérdés. Miért vannak olyan xenes *.cfg konfigok ahol a 100 -ba "látó" br hez(bridge=br100) még hozzáírtad az model=e1000 , esetlegesen latency probélmák voltak es azért vetted lejebb 1Gb/s a domu interfacét, vagy bn2nx nem birta?

Ja és
BTW.: Mire gondolsz az alatt, hogy a jumbo újratesztelése?
ping -s 8900 -M do 10.101.11.11 ?
esetlegesen , valahol valami a két eszköz közt megváltozott, és nem tudja végig a jumbot-t .

Még valami, szerintem az icinga átver.
Mert ugye a domu os-e nem látja a volumékról készített snapshotokat!!!
És a snapshotok a volumékról a helyet magában a volume tárhelyéből veszik el!
Például van egy 10GB volumém amiről naponta készitek snapshotot (mondjuk az napi szinten 200MB) heti 7*200 szinten pörgetve akkor is lefoglal 1.2GB-ot folyamatosan. Az domu os-e meg növegszik, egy kis sql itt, egy kis apache log ott. eléri a 8.8GB és szeretne bele írni, de amit nem lát, hogy ott van snapshotok. Az icinga pedig még nem is warningol mert szerinte több mint 10% szabad hely van!!!

Ha rám hallgatsz, lassítasz egy kicsit és megnézed a ZFS-t kicsit közelebbről. Kitapasztalod, miként működik, honnét és mivel nézve mit mutat, mivel felügyelhető, mit hogyan csinálnak vele mások. A kapkodás nem segít ilyenkor...
------------------------
{0} ok boto
boto ?

ZFSonLINUX-on
Tulajdonságok:
teszt/teszt_disk used 1,74G -

teszt/teszt_disk referenced 1,59G -
teszt/teszt_disk compressratio 1.00x -
teszt/teszt_disk reservation none default
teszt/teszt_disk volsize 4G local
teszt/teszt_disk volblocksize 8K -
teszt/teszt_disk checksum on

teszt/teszt_disk usedbysnapshots 152M -
teszt/teszt_disk usedbydataset 1,59G -

teszt/teszt_disk refcompressratio 1.00x -
teszt/teszt_disk written 152M -
teszt/teszt_disk logicalused 1,54G -
teszt/teszt_disk logicalreferenced 1,41G -
teszt/teszt_disk snapshot_limit none default
teszt/teszt_disk snapshot_count none default
teszt/teszt_disk snapdev hidden default

Már hülyének érzem magamat, de itt:
teszt/teszt_disk logicalused 1,54G -
teszt/teszt_disk logicalreferenced 1,41G -

azt írja, hogy a valós adat 1,4G?? és a "ref" 1,54 közti különbözet (140MB) pedig a zfsnek esetlegesen valami technikai adata.És ezt honnan foglalja le type volume estén?

A domu ebből csak 1,3 lát. A 4GB disk az stimmel nála.

azt írja, hogy a valós adat 1,4G??

Nem.
Ezt irja

logicalreferenced
The amount of space that is "logically" accessible by this dataset.
See the referenced property. The logical space ignores the effect
of the compression and copies properties, giving a quantity closer
to the amount of data that applications see. However, it does
include space consumed by metadata.

This property can also be referred to by its shortened column name,
lrefer.

Az a 140 (helyett 152MB!), az az amit a snapshotok elhasznalnak.
A honna kerdesre pedig a valasz: a pool-bol. Ezert van pool-od.
Abban lakoznak a dataset-jeid.

Mit ertesz amugy az alatt, hogy a domU ebbol csak 1,3-at lat?
Csak tippelek: A zvol-od ki van ajanlva iSCSI-n, es van a vegen egy... pl. xfs.
Es a domU-ban a df 1,3G-t mond.
Noss, ha erre gondolsz, akkor megint tevedsz. A df az eppen allokalt teruleted.
De tegyuk fel, csinalsz egy tok ures fajlrendszert. Most az egyszerusites kedveert, vegyuk ugy, hogy a journal az 0-t foglal rajta.
Majd rairsz 10 db. 100 megas fajlt.
Majd meg melleirsz mondjuk 5-ot.
Majd random valasztasz 2-t, amit letorolsz. A df 1,3G-t fog neked mutatni. De a lemeznek 1,5GB-nyi teruletere mar irtal.
A zfs errol nem tudhat (hiszen csak egy "buta zvol") arrol mi van folotte reteg. Aszerint te tenyleg elhasznaltal 1,5GB-t.
Hacsak nem megy vegig a folote levo fajlrendszeren egy paranccsal, ami blokkszinten trimmeli neked a szabad teruleteket, addig neked 1,5GB marad "referenced".
(Mar jo esetben, ha eleg uj zfs/zpool -d van, es ha tudja azt, hogy ha a folotte levo iSCSI-n trim van, akkor azokat a blokkokat csak siman elengedi.)

Szakadj már le a ZFS-ről!

A probléma az iSCSI összeköttetéssel / konfigurációval van, ez messziről bűzlik.
Azt nézd meg, hogy az iSCSI-nál mi gurul szét, amikor szétgurul.

Csak _egyszer_ maradj nyugodt, és higgadt, mikor megáll a rendszer, és akkor ne a rendszer tökönrugdalásával próbáljátok a hibát orvosolni, hanem megnézni, hogy mi az IGAZI probléma. Mert az itt már 100%, hogy semmi köze nincs a ZFS-hez.

Amit meg a snapshotolásról írtál, nettó baromság, értelme sincs!

Uff!

( fsanyee | 2017. 01. 31., k – 21:37 )

ha "wait modban" van a pool akkor a statusa nem online hanem unavail/suspended. olvasas talan mukodhet, de inkabb nem.

Eleg egyszeru leemulalni egy virtualboxban.
Fogsz egy szimpla gepet. Beledobsz 3+1 virtualis lemezt.
A +1-re mehet egy rpool az os-el. A tobbibol meg csinalsz raidz-t pl.
Majd kirugsz a masik pool-bol ket lemezt.
Azt nem fogja tudni online-ba tenni neked.
Ha csak 1-et, akkor elmegy tovabb degraded-ben.

Hát ez igen csak téves feltevés! A rendszer hiba nélkül pörgösen müködik, csak mostanában kezdett el rendetlekedni. Ami akár hardware hibából is fakadhat!
Az, hogy én itt kérdezősködök a sajnát tapasztalatlanságom átka!
Örülök,ha valaki egyátalán szóba áll velem, és segit!