nfs4 unhandled error 10018

Linux-haladó

Sziasztok,

 

Az alabbi NFS4 hiba gyakran elofordul egy adott esetben:

 

https://i.ibb.co/b7VZSBJ/image.png

Csak a kliens restart oldja meg sajnos a gondot... Van valakinek ra otlete, vagy talalkozott hasonlo hibaval?

 

A hiba leirasa

13.1.3.4. NFS4ERR_RESOURCE (Error Code 10018)

For the processing of the COMPOUND procedure, the server may exhaust available resources and cannot continue processing operations within the COMPOUND procedure. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.

  • 182 megtekintés

( Vamp | 2024. 02. 18., v – 12:14 )

kiegeszites, a fenti hibat ez elozi meg:

 

nfs4_reclaim_open_state: unhandled error -10026

( golgota | 2024. 02. 18., v – 12:29 )

Ugye a server szamara egy compaund-ban jo sok operacio van. Ezeket megprobalja szepen egyesevel vegrehajtani, de z egyiknel elakad. vagy azert mert nem tudja vegrehajtani (balmi hiba miatt) vagy ahogy fent is irtad elfogynak a resource-ok. Aztan ezt vissza is kuldi a kliensnek. 

Bar a bad sequence id number error a locking eseten mast mond. Valami a kliens oldalon lehet, hogy ilyen furan kuldi a compaund-ot, hogy abban nem helyes a sorrend.

Passz hogy valamelyik trace-el ki lehetne e deriteni, hogy melyik lock sequence id-n hasal el es az mire vonatkozik. 

Nem lehet hogy tobb kilens akar ugyanazon az allmonayon dolgozni de a szerveren es valami collision van koztuk? Mondjuk az egyik torolne mikozben a masik irna vagy ilyenek?

Ez egy Docker swarm ami 3 node bol all. mind a 3 eleri az NFS-t (ez a kozos persistent store). Az adott service viszont nem replikated, csak egy peldanyban fut, szoval "elvileg" nem lehet olyan h mas irna/olvasna ugyanazt.

 

Erdekes azonban, hogy tobben is irnak hasonlo gondokat, de CSAK NFS4 alatt. Mindenki azt irja, h NFS3-ra visszavaltva megszunt a problemajuk.

valoszinuleg megszunik, hiszen ott nincs compound-ba csomagolt request lista amit sequence id alapjan kell sorban vegrehajtani, hanem ahogy jonnek egyesevel ugy vegre is hajtodnak. bar ugye ennek megvan a hatranya performance teren.

Amugy szerintem pont kontenerek eseten ha erosen gilerendszer hasznalo valami az nem nagyon jo. Mi egyszer beraktunk egy elegge terhelt graphite-ot kontenerbe. A cpu sys a sok context switching miatt olyan 70%-ban vitte a cpu-t (magas granularitasu adathalmaz volt, ugy negymillio fajta adatponttal, zaz annyi graphite file-al; persze nem volt mindig mindegyik irva, de nyitogatni es irogatni kellett oket eleg erost). 

Szoval en nem raknek kontener ala semmilyen elosztott de meg tavoli (iscsi) filerendszert amit erosen hasznalunk (vagy ahol sok a random read/write). Inkabb atdesignolnam az architekturat.