Filemeret para

Naplózó filerendszerek (journaling)

Tegnap este a fejlesztoink cuccait migraltam egy uj rendszerre, de amikor a /home-hoz ertem, meglepetes fogadott. A potom 1.x Gigas home, mar eleg sok ideje masolt ahhoz, hogy gyanakodni kezdjek, hogy valami nincs rendjen. Megszakitottam a masolast, es latom, hogy az uj particion a helyfoglalas 13G. Az ok, mint kesobb kiderult, egy az egyik programozonk homejaban levo javascript include file.Ime a jelenseg:

root@...# file jsfunctions.inc
jsfunctions.inc: ASCII C++ program text, with very long lines, with CRLF line terminators

root@...# du --si jsfunctions.inc
46k jsfunctions.inc

root@...# ls -lh jsfunctions.inc
-rwxr--r-- 1 david users 65G Apr 16 2005 jsfunctions.inc

root@...# df -h jsfunctions.inc
Filesystem Size Used Avail Use% Mounted on
/dev/md2 28G 1.5G 25G 6% /home

WTF?

Frank

PS: a /home egyebkent ext3.

  • 2011 megtekintés

( sany | 2006. 08. 08., k – 23:16 )

mivel másolod?

----------------------------------------------------------------
"A megoldas mindeki kerdesere egyszeru.
OLVASSATOK DOKUMENTACIOT!"
by thuglife

( sany | 2006. 08. 09., sze – 13:58 )

Nezd, ertekelem az otleted, de a fo problema nem az, hogy nem tudom atmozgatni (persze a vegso cel az lenne)

másolni sem?(rsync -av ip:/home/* ip:/home/* )

----------------------------------------------------------------
"A megoldas mindeki kerdesere egyszeru.
OLVASSATOK DOKUMENTACIOT!"
by thuglife

( nc | 2006. 08. 09., sze – 15:05 )

Itt elég nagy gáz van a fájllal, ezért a helyedben megnyitnám, elmenteném a tartalmát, a többi anyagot archiválnám és törölném a partíción a fájlrendszert.

( pasztorl | 2006. 08. 09., sze – 15:09 )

Biztosan fajlrendszer hiba.
Amikor fsck-ztal milyen opciokkal tetted?
Lehet nem futott ra.
Vagy durvabban kell rajta vegigmenni fsck-val es megoldja, vagy kuka a fajlrendszer.
(gondolom abban biztos vagy, hogy mas process nem hasznalja a fajlt)

( egmont | 2006. 08. 09., sze – 16:04 )

root@...# du --si jsfunctions.inc
46k jsfunctions.inc

root@...# ls -lh jsfunctions.inc
-rwxr--r-- 1 david users 65G Apr 16 2005 jsfunctions.inc

Ez teljesen normális jelenség, nincs ebben semmi para, semmi fájlrendszerhiba. Ha megnyitsz írásra egy fájlt, előretekersz benne (fseek) 65 GB-ot, majd írsz bele néhány byte-ot, ez lesz az eredmény. A fájl eleje egy rakat nulla, de az nincs letárolva, csak leadminisztrálva, hogy ott bizony rakat nullás blokk van.

Az "ls -l" a fájl méretét mutatja, ami 65 GB, a "du" pedig nevéhez híven a diszkből elfoglalt mennyiséget, ami alig néhány kB.

Az ilyen fájlokat "sparse file"-nak hívja a szakirodalom. A cp parancsnak külön opciója van ezek kezelésére, lásd man cp. Egyéb parancsok (tar, cpio, rsync stb.) is lehet hogy támogatják az ilyen fájlok "okos" másolását (tehát hogy a másolat se foglaljon sok helyet), de lehet hogy nem, egyenként meg kell nézni a progik leírását. Természetesen ha simán másolod az ilyen fájlokat, akkor a másolat 65 GB nagyságú lesz, hiszen egy sima megnyitás és olvasás során kapod a nullás byte-okat dögivel, de nem értesülsz róla, hogy sparse fájlról lenne szó.

Tobbek kozott arra lehet jo, ha keszitesz egy image-t, ami esetleg egy virtualis gep-nek ad otthont, akkor a letrehozaskor meg tudod adni, hogy mekkora is legyen maximalisan az a file, de a lemezen elfoglalt helye dinamikusan novekszik, ahogy toltod meg tartalommal (persze szamtalan felhasznalasi modja lehet meg). Ismertem, hasznaltam sparse file ficsort korabban, csak azt nem ertem, hogyan lehet ilyet letrehozni 'veletlenul'?

Kosz a tippet egmondt. Es mindenki masnak a hozzaszolasokat.

> azt nem ertem, hogyan lehet ilyet letrehozni 'veletlenul'?
Tudod, végtelen sok majom még a Shakespeare-összest is legépeli 'véletlenül'. ;)
Egy lehetőség: a dd skip és seek paraméreterét összekeverte valaki. Valahogy így:
dd if=/dev/urandom of=/tmp/foo bs=512 count=1 seek=500000
Egyébként szívesen, de ha kérhetem, d betű nélkül :-)

"Egyébként szívesen, de ha kérhetem, d betű nélkül :-)" - Ugy akartam, ne haragudj.
(Hezitaltam kicsit, aztan a vegen ugy nez ki mindketto lett belole.)

Azt vagtam, hogy a megfelelo eszkozokkel hogyan hozol letre egy ilyen file-t, de egy samba share-n keresztul Windows alol, raadasul ugy, hogy a file elso nehany 10 kilobyte-ja legitim tartalom... Az elet nagy kerdesei ugye.

Nekem pl az Azureus torrent kliens is csinál ilyet. Mire jó? Van letöltés célra ~12 Gb partícióm. Ez biza 3 DVD-val meg is telhet, de nem telik meg, mert úgy hízik a fájlméret, ahogy töltök. És addig tudok onnan seedelni addig is.

Bár a jelenség ismert volt esetemban, ötletem sem volt a 65Gb-os fájl problémájára :)

vagy nekem vannak félreértéseim, vagy erre az általad említett dologra nem kell a fenti fícsör. erre az append is elegendő lenne (egy file helyfoglalásánál sosem kell előre tudni mekkora lehet. ha van hely, majd a rendszer lehetőségeihez való eszközökkel bővíted, pl. append).

számomra továbbra is nyitott kérdés a sparse haszna (egyet tudok elképzelni, pl. nulla byteok kiolvasása, de arra csak elég lenne egy device is, ami csak nullát ad vissza, nem? és ilyen már van). az azureus hogy használja ezt a feature-t?

Jó, appenddel is nő a méret, de nem az a cél, hogy csinálj egy bármilyen tartalmú nagy fájlt, hanem hogy csinálj egy olyan fájlt, amiben az van, ami neked kell. Ha a fájl diszk image, amibe a belső oprendszer a saját kedve szerinti helyekre irogat, vagy egy letöltendő cucc aminek darabjai összevissza sorrendben érkeznek, akkor ezt hogy oldod meg hozzáfűzéssel? Ilyenkor pont erre van szükséged: csinálsz egy baromi nagy fájlt, melybe adott helyekre írsz kevéske adatot, a többi helyen nullák állnak, és nem árt, ha nem foglal le annyi helyet, mint amekkora a fájl igazi mérete, hanem csak jópár nagyságrenddel kevesebbet.

( gorgo75 v | 2006. 08. 09., sze – 16:31 )

dd vel is lehet én qemu-img vel csináltam most a kedvedért

qemu-img create uff 65G
# ls -lh /root/uff
-rw-r--r-- 1 root root 65G 2006-08-09 16:05 /root/uff

-rw-r--r-- 1 root root 65G 2006-08-09 16:05 uff
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 29G 26G 1.9G 94% /

ps. Még annyi, hogy értékelendő a segítség, de azért ha nem vagytok biztosak ,inkább ne írjatok.(egmont -ra nem vonatkozik)

Pl biztos rossz a filerendszer , nyomj fsck, meg törölt az egész fs-t...stb.... üdv

Természetes "ingyen" adunk tanácsot, de annak következménye van és ezér felelőséggel tartozunk annak akinek adjuk.
Pl ha nem vagyunk biztosak akkor azért jelezzük.

nem bántásnak szántam, értékelendő minden hozzászólónak a jó szándéka.
Remélem senkit nem bántottam meg.

üdv jó éjt

No offense, de pl a filerendszer problema teljesen helyenvalo feltetelezes, egy linux - legalabbis szamomra - nem feltelenul azt jelenti, hogy azonnal megoldasom van egy adott problemara. Masreszrol velem fordult elo hasonlo problema (egy iso volt sokkal nagyobb mint amekkora a merete) es az filerendszer problema volt. Te mindig biztos vagy benne, hogy mi a problema? üdv

A feltételezésem az volt, hogy azért ad a két parancs eltérő eredményt, mert megsérült a fájlrendszer. Voltaképp ilyen "átveréssel" él az említett megoldás is, csak ez "legális", lehet kezelni. Az igaz, hogy az fsck-nak hibát kellett volna jelezni, mégpedig azért, mert a fájl vége "elmászott". Hogy mégse tette, azért javasolt a fájlrendszer újraformázása, mert akkor a hiba nem biztos hogy javítható fsck-val (van ilyen).
Mivel nem foglalkoztam én se és sokan mások se közülönk ilyen fájlokkal, ezért nem tudhattuk, hogy a dolog normális is lehet. Az kérdés, hogyan keletkezett Samba megosztáson keresztül, Windows-al. Szvsz. én mégis formáznék...