Ubuntu 10.04 server 64 bit.
Egyelőre Google-n keresem, mi lehet a gond. De bízom benne a kollégák esetleg láttak ilyet és csípőből vágják a megoldást.
Előre is köszönöm!
KAMI
- KAMI911 blogja
- A hozzászóláshoz be kell jelentkezni
- 1243 megtekintés
Hozzászólások
Hello, esetleg valami reakcio erre??
- A hozzászóláshoz be kell jelentkezni
Sajnos egyelőre nem volt időm kísérletezgetni vele. A storagenak szán cuccrol levettem a fájlokat és egyelőre máshogy oldottam meg. De átnézem és jelentkezem, hogy mire jutottam.
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
- A hozzászóláshoz be kell jelentkezni
+sub - mert hogy nálam egy 326m csinálja ezt az utóbbi időben és rá nem tok jönni mi a nyűgje!? Érdekes módon csak 64 bites Ubuntuval, Debiannal semmi baja nem volt előtte
- A hozzászóláshoz be kell jelentkezni
Ez a bug a 8.04-es ubuntutól (32bitben tuti) már létezett és ez az oka annak hogy letettünk az OCFS2-ről teljesen. És emiatt utálta meg egy kollégám az Ubit naon... Nem hittem volna hogy 10.04 64biten viszontlátom. Azóta mi nfs-re loggolunk egy gépen, és nfsről kiszolgálunk egy másik gépen és az OCFS2 höz képest 3-7x sebességgel, és azóta hiba nélkül.
Sajnálom hogy segíteni nem tudtam, de nem jósolok sok jót ha OCFS2ről van szó.
- A hozzászóláshoz be kell jelentkezni
NFS-el csinálsz redundanciát?
--
2e845cb4c3a5b5bd6508455b1739a8a2
- A hozzászóláshoz be kell jelentkezni
talalkoztam vele
storage-nek szant peeceen fordul elo egeszen rendes diszkterheles mellet. Volt mar szintetikus tesztnel es egyszeru raid szinkronnal is.
megoldas nincs. esetleges kernelverzional elojon, masnal nem. Volt vanilla kernellel es disztrib kerneljevel is.
Ugy gondolom, hogy a diszkek iranyaba nezo low-level driver es mas kernelrendszerek inkompatibilitasa a ludas.
Nagyjabol ez az az ok, ami miatt, ha vegre van egy olyan storage szerver osszeallitas, ami mukodik,a kkor ahoz 5 evig nem nyulunk (nincs upgrade)
- A hozzászóláshoz be kell jelentkezni
Egyik szemem sír, másik nevet... Egyrészt örülök, mert ezek szerint nem feltétlen én vok a ludas. :) Viszont ezek szerint a reménykedésen, hogy egyszer összeáll a rendszer más nem nagyon marad :(
Esetleg nincs vkinek tippje, hogy egyedi kernellel hogyan lenne ez kiküszöbölhető? Vagy az sem járható út?
Egyébként érdekes amiket írtatok. Nálunk is egy storage -nek használt gép tolja ezeket a hibákat. Virtuális gépek merevlemezkép fájljai lennének rajta + irodai megosztás.
- A hozzászóláshoz be kell jelentkezni
ketteszeded a projectet. Varhatoan a feladat nem irgalmatlan IO intenziv, megengedheto, hogy kulon storage legyen es kulon virtualizacios rendszer.
A kulon storage (amiben sok-sok diszk van)
es a kulon virtualizacios gep (amiben sok-sok memoria es cpu) etherneten van osszekotve, es iSCSI -vel vagy nfs-sel viszed at a az adatot. Igy a storage gep nagyon-nagyon egyszeru tud lenni, es van eselyed talalni egy olyan kernelt, amivel fut. Harom-negy verzio vegigprobalasaval altalaban osszejon egy nem stuckolo konfig. Mivel a hiba eloidezesehez eros terheles kell, igy terhelesgeneratort kell csinalni, amivel a hiba jol reprodukalhato. Ez sokaig tart
- A hozzászóláshoz be kell jelentkezni
köszönöm a választ és a segítséget, amint lesz rá időm asszem nekilátok :)
- A hozzászóláshoz be kell jelentkezni