"Stale NFS file handle" + XFS + inode64

Van egy particiom, amirol exportaltam egy konyvtart. A mount rendben lefutott, de folyton ezt az uzenetet kaptam, amikor a konytarba megprobaltam belepni.

A legszebb, hogy umountolni sem lehetett. Sot reboot-olni sem tudott (Ubuntu 12.04), csak a reset segitett (igy echo b > /proc/sysrq-trigger segitsegevel kiserletezgettem, a mellette levo irasban levo zfs jol vizsgazott eddig:)

A szulo konyvtart exportalva siker, de nem latom a mellette levo konyvtarakat, csak azt, amelyiket eredetileg akartam megosztani. Ha belemegyek, akkor ugyanez az uzenet. De legalabb lehet umountolni.

http://oss.sgi.com/archives/xfs/2009-11/msg00161.html

Az nfs inkompatibilis az inode64 mount opcioval.

man mount:

inode64
Indicates that XFS is allowed to create inodes at any location in the filesystem, including those which will result in inode numbers occupying more than 32 bits of significance. This is provided for backwards compatibility, but causes problems for backup applications that cannot handle large inode numbers.

Azaz egy szo sincs az nfs-rol a dokumentacioban, valamint a datumbol is latszik, h nem ma jutott a felszinre ez az issue/feature.

A megoldas a fenti linken szerepel, keresni kell egy olyan konyvtart, aminek az inode szama alacsony es azt megosztani.
Ill. elvileg mukodik az fsid=0 vagy az fsid=uuid is, nekem egyelore nem igazan.

A hajam kitepem.

tompos

Hozzászólások

# umount /1
/1 was not found in /proc/mounts
/1 was not found in /proc/mounts

Nem lehet umountolni, de listazni kozben mukodik. Ez egy amolyan felig ilyen, felig olyan fs. De utalom az nfs-t..

En ezert nem hasznalok XFS-t, hacsak lehet. Akarhol probaltam meg eddig felhasznalni - mindig szivas lett a vege. Erdekes modon, ugyanez ext3-mmal sosem okozott problemat. Nincs ugyan inode64 feature-e, de legalabb elbokni sem tudom.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az mc-re nem mondja senki? Nocsak, ezzel mar 10 eve is kirohogtek. Utodjelolt nincs, az teny.

Mindenesetre almat a traktorral:)
Az fs-ek teren egyszeru atmeneti idoszakrol van szo szerintem. Abban sem vagyok biztos, hogy 10 ev mulva hasznalatban lesznek-e meg az a mai ertelemben vett fs-ek...

tompos

Ha husz eve gyakorlatilag alig modosult a fajlrendszerek alapveto mukodesi logikaja, akkor az elkovetkezo husz evre se josolok nagyon mast. A blokk alapu tarolasi modon nem olyan egyszeru tullepni.

Ettol eltekintve talan igazad van. Ugyanakkor felhivnam a figyelmedet arra, hogy az utalt, lenezett, tobbszor temetett FAT32 meg mindig viragkorat eli a kulonbozo eszkozoknel, mint pl. egy fenykepezogep. Es bar az optikai adattarolas is rengeteget fejlodott, az alapveto ISO9660 es kiterjeszteseinek letrejotte ota nagyon mas jelentkezo nem volt, aki el akart volna terjedni. Az Apple a HFS-sel inkabb csak a vicc kategoriajaba sorolando.

Szoval az eddigi tapasztalatok alapjan az FS piacon inkabb a kiprobalt, megbizhatonak titulalt rendszerek sikeresek.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A FAT32 embedded termekekben hasznaljak es ott is keresik az utodjat erosen, mivel erzik a gyartok a korlatait.

Az isofs is egy eleg specko terulet, minek lecserelni, ha az is lehet, h eleve a media fog eltunni alola?

> kiprobalt, megbizhatonak titulalt rendszerek sikeresek.

Egy olyan teruletesen, mint az FS, mindig is igy lesz, de a legtobb egyeb temaban is.
Ettol fuggetlenul fejlodik es latszik is az igeny, h mire van szukseg. Ekes peldaja ennek, a cow, az fs-sel egybeepitett volume kezeles, raid, hot data tracking, cluster awaring, compress, dedup, valtozo blokkmeret... etc.

Szerintem az mar latszik, hogy az ext* xfs es a tobbi felig-meddig regivagasu rendszert max. patkolni lehet, de hosszabb tavon valtoztatni kell az alapokon.
A melot el is kezdtek, csak meg stabilizalni kell, legalabbis nyilt forras korokben.

tompos

Igen, csak nekem az a problemam ezzel az egesszel, hogy mindenhez, ami a Linux kernelen belul novekszik, kicsit felve kozelitek stabilitasi szempontbol. Tudod, aki egymas utan tobbszor is megegette magat, az nem egyszeruen csak keruli a tuzet, hanem mely bizalmatlansagot is taplal iranta.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Felreertetted, en a fejlesztesre ertettem, hogy ami a Linux kernel fejlesztesen belul fejlodik, azzal kapcsolatban vannak ellenerzeseim, tehat ami be lett emelve a Linux kernelbe. Vagy nem tudom, hogy mondjam, szoval, ami a kernel.org berkein belul fejlodik.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

En elsosorban nem a ZFS-re ertettem, hanem altalaban a Linux kernel berkein belul fejlesztett FS-ekre (elobb utobb csak reszletesen le kell irni mindent, a lustasag megbosszulja magat), ezen belul is foleg az "ujdonsagokra", vagy a kevesbe elterjedt cuccokra. Nekem peldaul eddig se az Ext3 se a Reiser nem hozott nagyon csunya meglepeteseket, de mind az Ext4 mind pedig az XFS nagy csalodasokkal halalta meg a komolyabb erdeklodest, valahogy instabilabbak voltak a jol bevalt FS-eknel. Persze, ez lehet, hogy csak az en egyedi szemelyes tapasztalatom, de ez az, amibol a bizalmatlansag taplalkozik, nem is rosszul. Nagyon sok adat veszett mar igy el, es - foleg az XFS miatt - volt mar ejszakazasom is.

A ZFS-nek azert adtam eselyt, mert szeretnek dolgozni Mac es Linux alatt is egyszerre, egy gepen belul, laptopon, hordozhatoan. Eddig HFS-t hasznaltam journaling nelkul, de Linux alatt annyira instabil az a fajlrendszer, hogy ugy dontottem, ennel meg egy total ismeretlen ZFS is jo lehet. Jobb is lett, bar tenyt, hogy mocsok lassu, de legalabb stabil, birja a gyurodest, nem kell minden este azzal lefekudnom, hogy vajon reggel nem-e a tegnapelott esti mentesbol kell inditanom a fejleszteseket.

Ami ujfent megerositett abban, hogy eroteljes fenntartassal kell kozeledni minden fele, ami a Linux kernelen belul novekszik - lehet, hogy nagyon jo, de szenne kell tesztelni (vagy rengeteget utanaolvasni), mielott az ember hasznalni kezdi, akar otthoni, vagy teszt celokra is.

A Linuxszal elsosorban nekem a kernel a problemam. Peldaul a stabil Gnome, KDE vagy IceWM kiadasokkal sosem volt bajom, az alap userland mindig mukodik, a legtobb programmal jo tapasztalatok vannak, egyedul a kernel az, ami rendszeresen megszivat - meg itthoni kornyezetben is. Na meg a disztribuciogyartok.

Es nem azt mondom, hogy szar, csak nem bizok meg feltetlenul mindenben, ami onnet jon.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

FS-eknel szerintem ez mashol sincs igy.
Konkretan Linux-on a reiser eseten tutira emlekszem oltari nagy szivasokra. Solaris-nal pedig a zfs-nel volt a korai idoben adatveszteses cumi.
Valamint persze volt nekem is ext* mindennel bajom. Konkretum ami most eszembe jut, ott fogalmam nincs, h az fs hibazott, vagy mas gond volt, de valoszinu, h az fs, mivel idovel megritkultak a hasonlo hibak, azaz javitothattak.

Az FS-ek eletciklusa ilyen, kell neki hosszu ido, mire felnottnek nyilvanithato es utana meg hosszu ido, ha komoly munkat lehessen rabizni, de meg akkor is csak naivsag nelkul.

A kernellel pedig alapvetoen nincs problemam, altalaban hozza, amit elvarhato tole. Inkabb csak azzal volt problema, ami uj funkcio. Igaz, az valoban hozta meg az experimental jelzo leszedese utan is (az is igaz, h forditva is szokott stabil lenni korlatokkal kezelve).

Mas rendszeren sem tapasztaltam ezt mashogy, bsd-vel, windows-zal es karcsu mennyisegu solaris-szal van tapasztalatom.

OS X-hez szerenncsere nincs kozom.

A userland _joval_ tobbet szivat, latszik, hogy nagy altalanossagban feluletesebb fejlesztok hatnak ra. Mondom ezt ugy, h sokszor cutting edge kornyezetet hasznalok.

tompos

Nem tudom, nekem regi dolgokkal is gyult mar meg a bajom. Xen, LVM, kulonfele driverek, hosszu a lista, egyikrol sem akkoriban esett le az EXPERIMENTAL cimke.

Userland oldalon eddig csak olyasmi szivatott meg, ami kozismerten gazdag forrasa az ilyesminek: PHP, Apache, DRBD (mondjuk ez nem engem, csak kozom volt hozza), kulonfele zartforrasu izek.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ven roka vagyok mar, amikor en foglalkoztam drbd-vel komolyabban (virtualis kornyezetben) akkor meg fordult hozza a cucc. Az eset amit emlitettem pedig mar feltelepitett drbd-vel volt, amit nem en telepitettem/raktam ossze, szoval nem volt infom arrol, hogy ez valtozott...
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

gondolom, 1 TB-nal nagyobb a particiod, es kenytelen voltal 64-bitet hasznalni. Ha a 64-bites xfs es az nfs utik egymast, esetleg a jfs hasznalhato, bar az eleve szetszorja az inode-okat a particion...

Diktatorok kezikonyve

xfs is belassul mint állat, igaz en csak 9TB-s köteten használtam. :)
véleményem szerint az egyetlen jo fs manapság a zfs, bár aval is vannak azért nyűgök. pl. jó ha hagysz 10% körüli szabad helyet, külömben az is belassul, a rewrite lassu tud lenni, mert felolvassa az eredeti blokkokat, stb.
várom én is az fs forradalmat, emlekezeteim szerinte regebben nem volt ennyi szivas az fs-ekkel.

Nekem se szokott panaszkodni, ha arra gondolsz, hogy hibakat logol. "Mindosszesen" tizedere esik vissza az I/O sebesseg. Bagatell hiba, mondhatni. Kis takaritas altalaban megoldja. Mondjuk nekem fel tera alatti diszkjeim vannak, nagyreszt virtualisak (LVM LV), de akadnak fizikaiak is, ahol a jelenseg ugyanigy nez ki.

Talan van valami konkret merethatar, ami ala nem jo menni, nem tudom, 20T -nal az 5% is meg ~1T koruli meretet jelent, ha jol szamolok, vagyis ott meg a 95% is jonak szamit.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal