miert telt be a particio?

FreeBSD-all

Sziasztok!

Van egy FreeBSD-s gep (5.3-RELEASE FreeBSD 5.3-RELEASE), amin a kovetkezot tapasztaltam. Az egyik particio valami miatt elkezdett betelni valamitol, eljutott 100% fole. Probaltam rola torolni dolgokat, csokkent a foglaltsag, de meg mindig ment felfele. Aztan egyszercsak "gondolt egyet" es visszaesett 72%-ra.
Ezutan ugyanezt eljatszotta a gyoker particioval is. Itt 108%-ra nott, aztan hirtelen leesett 7%-ra. Kozben nem csokkent, hiaba toroltem rola...

Mindket esetben a novekedes alatt nem talaltam olyan faljt, ami nott volna.

Valaki talalkozott mar hasonloval?

  • 1647 megtekintés

( rpsoft v | 2007. 11. 04., v – 12:59 )

Nem lehet, hogy olyan file-t töröltél, amit épp egy program megnyitva tartott?

( trey | 2007. 11. 04., v – 13:42 )

Tipp: softupdates.

A / partícióra nem javalott a softupdates. Van egy olyan tulajdonsága, hogy teli filerendszerről letörölt file esetén csak kb. 2 perc múlva mutat szabad helyet.

1) On filesystems that are chronically full, the two minute lag
from the time a file is deleted until its free space shows up
will result in premature filesystem full failures. This
failure mode is most evident in small filesystems such as
the root. For this reason, use of soft updates is not
recommended on the root filesystem.

--
trey @ gépház

Igen, eppen folyamatban van a gep(es oprendszer csere, a masikon 6.2 van), de szerintem ez a fenti problemat (novekvo nyitott fajl torlese) nem oldja meg.
En ezt inkabb a h*lye juzer kategoriaba sorolnam (aki jelen esetben En voltam) :)
Tehat a jovoben megprobalom elkerulni az effele bakikat...

Most azt probalom kideriteni, hogy ha egy olyan file van nyitva, aminek a merete no, es kozben letorlodik, akkor hogy lehet meghatarozni, hogy mi teliti a particiot. Mert mivel nem jon letre ujra, az a progi, ami korabban novelte, az tolna tovabb bele az adatot, de mar nincs fajl, viszont a particio telitettsege no...
Tehat ha megnezem "lsof"-al vagy "fstat"-al, akkor mar nem latom a nyitott fajlt, es nem tudok mire keresni...

( yndy | 2009. 02. 28., szo – 09:37 )

Ujra elofordult egy hasonlo eset...
A helyzet az, hogy egy particio eseten a "du" es a "df" nagyon(>60Bb a df javara) kulonbozo erteket mutat.
Probaltam keresni mar letorolt, de meg valamely process altal nyitott fajlra es talaltam is. Viszont kilove a process-t, meg mindig maradt a kulonbseg. Ezutan probatam keresni sparse faljlokra, de nem talaltam.
Van-e valami mod arra, hogy kideritsem miert van ekkora kulonbseg a "du" es a "df" kimenete kozott?
Rendszer: FreeBSD 7.0-RELEASE

Az ismertebb lehetőségek:

a) (ezt írtad is) van egy fájl, amit valaki nyitvatart, és (esetleg más)valaki töröl. Ilyenkor az alkalmazás változatlanul tudja írni/olvasni, ellenben ls-ben nem látszik, du nem mutatja, de df-ben hatása látszik. Ellentétben a korábban írtakkal, ha nem is könnyen, de lsof -fel megtalálható.

b) mount-könyvtárban van. pl: /usr és /usr/local két külön FS, viszont (trehányságból/tudatosan) a /usr/local eredendően nem üres. Az ott levő fájlok persze df-ben számítanak, viszont mihelyt mountolod /usr/local -ra amit kell, azonnal eltűnnek és nem tudod számolni du-val.

A df/du különbség szerintem simán adódhat abból, hogy kilőtted ugyan a processzt, de valaki más is ugyanazt a fájl használta. (Legalábbis szinte biztos, hogy ha én találok egy ilyen elhagyott fájlt és megtalálom a hozzá tartozó processzt, nem keresek tovább. Kilövöm, és kész. De ha ez nem segít, akkor ez azt jelenti:

a) van más aki használja
b) van másik ilyen törölt fálj
c) vagy mint Trey is említette korábban, softupdates. (Ez ügyben érdemes elgondolkodni a

kern.filedelay=10
kern.dirdelay=9
kern.metadelay=8

sorokat beírni a /etc/sysctl.conf -ba (Nyilván környezetföggő, hogy mennyivel kaarod a SU késleltetését csökkenteni. Ezek az értékek 20 sec-cel kevesebbek az alapértelmezettől.)

d) eset is lehet, de azt nem tudom.

Ha nagyon nincs meg, akkor az általad korábban is említett fstat és lsof mellett, én elgondolkodnék a (portsból telepíthető) sysutils/fuser előbányászásának (bár az lsof többet tud), illetve egy fsdb -r /problemas/fs és elkezdenék körülnézni.

Jav:

Amúgy lsof kimenetben, ha VREG (azaz közönséges fájl) tipus esetén nem fájl, hanem könyvtárnevet látsz (plusz zárójelben eszköznevet), akkor nagy eséllyel meg is van a bűnös, lehet gyanakordni. Mivel a listában látszik a mérete, lehet látni ha növeksik, és látszik az i-node száma is, tehát meg lehet keresni "find dir -inum" -mal (nem kéne találni), és meg lehet nézni fsdb-ben az inode SZÁM paranccsal, jó esélyen a linkcount 0 lesz. (Érdekes egyébként, nekem tesztek közben többször előjött, hogy az első fsdb szerint még van linkje, a másiodik szerint már nincs.)

MEGTALALTAM :)
Huh, sikerult megtalalni...
Tulajdonkeppen a fstat segitett. Talaltam egy olyan inode szamot, amit a "find / -inum inodeszam" nem talalt meg. A httpd process-hez tartozott. Ujrainditottam a httpd-t es most mar a "du" kimenete egyezik a "df" kimenetevel :) Csak azon csodalkozom, hogy tegnap is ujrainditottam mar a httpd-t, es akkor nem volt hatasa...talan most tobbet vartam a leallitas utan... :)
Koszi megegyszer a segitseget!