ext3 - elfogyó inode
Zs
Hi!
Egy 700GB-s köteten sikerült bele futnom abba
a problémába, hogy a 89%-os foglaltság mellett
a kötet tele van, nem írható. Ez azt jelenti,
hogy bár kicsit több mint 70GB szabad, mégsem
tudok rá írni, mert sz inode-ok elfogytak.
A kötet backup célokra használt, a napi mentésnél
ha nincs változás egy file-ban, akkor van egy
hardlink arra, így ez külön helyet nem foglal,
viszont emiatt a szokásos inode felhasználás
többszöröse van a köteten.
A kérdés az, hogy van-e mód arra, hogy utólag,
adat vesztés nélkül növeljem az inode számot
a szabad hely rovására. Ha szükséges, a kötet
kicsatolható, tehát off-line művelet lehetséges.
A témában már kugliztam egy sort, de sok bíztatót
nem találtam. Eddíg egy tippet kaptam: mentsem
le a kötet tartalmát, a hard linkeket tartsam
meg úgy, hogy rsync -a viszi át a cuccost, tegyem
újra az fs-t, majd vissza az egészet.
Más megoldás valóban nincs?
Üdv
Zsolt
_________________________________________________
linux lista - li...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Andras HORVATH
Zs <hor...@freemail.hu> wrote:
>
> A kérdés az, hogy van-e mód arra, hogy utólag, adat vesztés nélkül
> növeljem az inode számot
Nincs (vagyis hexeditorral maximum ;), de egy mentes-visszatoltes ennel
joval egyszerubb.)
> A témában már kugliztam egy sort, de sok bíztatót nem találtam. Eddíg
> egy tippet kaptam: mentsem le a kötet tartalmát, a hard linkeket
Ha ezt az utat valasztod, javaslom, hogy az uj filesystemed dinamikusan
foglalja le az inode-okat (pl. xfs).
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Zs
Hi!
>> A kérdés az, hogy van-e mód arra, hogy utólag, adat vesztés nélkül
>> növeljem az inode számot
>
> Nincs (vagyis hexeditorral maximum ;), de egy mentes-visszatoltes ennel
> joval egyszerubb.)
>
A hexeditorhoz olyan szintű fs ismeret kell, amely keveseknek van.
Én nem vagyok közöttük...
A mentés-visszatöltést azért nem érzem egyszerűbbnek, mert mint a
levél nem idézett részében említettem, nagyon sok a hardlink. Egy
sima copy minden file-t át fog vinni egy példányban, így a jelenlegi
630GB pillanatok alatt 2.5-3TB lesz. Vagy rsync -a és ki tudja meddíg
tart...
>> A témában már kugliztam egy sort, de sok bíztatót nem találtam. Eddíg
>> egy tippet kaptam: mentsem le a kötet tartalmát, a hard linkeket
>
> Ha ezt az utat valasztod, javaslom, hogy az uj filesystemed dinamikusan
> foglalja le az inode-okat (pl. xfs).
>
Maradt ez az út. Winyó csere és rajta xfs. Itt meg bebukom a 70GB-t,
majd egy év múlva amikor ismét ezekre indul a mentés, akkor már
figyelni fogok erre.
Köszi a válaszod.
Zsolt
Kiss Gabor
In article <4B0B9DD4...@freemail.hu>,
Zs <hor...@freemail.hu> writes:
> A ment=E9s-visszat=F6lt=E9st az=E9rt nem =E9rzem egyszer=FBbbnek, mert mint=
> a
> lev=E9l nem id=E9zett r=E9sz=E9ben eml=EDtettem, nagyon sok a hardlink. Egy
> sima copy minden file-t =E1t fog vinni egy p=E9ld=E1nyban, =EDgy a jelenlegi
> 630GB pillanatok alatt 2.5-3TB lesz. Vagy rsync -a =E9s ki tudja medd=EDg
> tart...
Ki mondta, hogy cp-t használj?
Barátod a tar, cpio, afio... soroljam? :-)
g
Zs
>> A mentés-visszatöltést azért nem érzem egyszerűbbnek, mert mint a
>> levél nem idézett részében említettem, nagyon sok a hardlink. Egy
>> sima copy minden file-t át fog vinni egy példányban, így a jelenlegi
>> 630GB pillanatok alatt 2.5-3TB lesz. Vagy rsync -a és ki tudja meddíg
>> tart...
>
> Ki mondta, hogy cp-t használj?
> Barátod a tar, cpio, afio... soroljam? :-)
>
Igen, kérlek sorold. Különös tekintettel arra a peremfeltétlere, hogy
a ha egy file 15 helyen szerepel, de ez hely tekintetében egyetlen file,
a másik 14 pedig hardlink, akkor őszintén érdekelne, hogy a tar, cpio,
afio és egyebek hogyan oldják meg azt, hogy detektálják a hardlinket
és a példabeli 15 file-t csak egy példányban viszik ki.
Jelzem, nem véletkenül írtam rsync-et, ott ugyanis a man szerint van
lehetőség a hardlinkek detektálására és megtartására...
man rsync
...
Note that -a does not preserve hardlinks, because finding
multiply-linked files is expensive. You must separately specify -H.
Zsolt
Gábriel Ákos
> Igen, kérlek sorold. Különös tekintettel arra a peremfeltétlere, hogy
> a ha egy file 15 helyen szerepel, de ez hely tekintetében egyetlen file,
> a másik 14 pedig hardlink, akkor őszintén érdekelne, hogy a tar, cpio,
Ez ugyan nem a flame, mégis talán kicsit flame-es stílusban válaszolok,
mert az eredeti levél is olyan, de ha kipróbáltad volna a tar-t mielőtt
pofázol, akkor rájöttél volna, hogy pl. a tar jól kezeli a hardlinkeket.
Én kipróbáltam.
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.g...@i-logic.hu|Web: http://www.i-logic.hu=-
-=Tel/fax:+3612391618 |Mobil:+36209278894 =-
Kiss Gabor
In article <4B0BB812...@freemail.hu>,
Zs <hor...@freemail.hu> writes:
>
> SGkhCgoKPj4gQSBtZW50w6lzLXZpc3N6YXTDtmx0w6lzdCBhesOpcnQgbmVtIMOpcnplbSBlZ3lz
> emVyxbFiYm5laywgbWVydCBtaW50IGEKPj4gbGV2w6lsIG5lbSBpZMOpemV0dCByw6lzesOpYmVu
... pax, ustar, ...
A válasz: igen.
A felsoroltak (szinte) mind vigyáznak a hard linkekre. Az rsync-kel szemben
itt külön kell sportolni, hogy ne tegyék.
(Na jó, a cpio-ért nem teszem tûzbe a kezem. :-)
tar(1):
--hard-dereference
during archive creation, dereferences hard links and stores the
files they refer to, instead of creating usual hard link members
(type '1')
afio(1):
The contents of hard linked files are (unless the -l option is used)
only stored once in the archive."
Legalább olvasnád el a mánuelt, mielõtt letámadsz...
Ha a mechanizmus érdekel, "use the source, Luke".
(De csodák nincsenek: hosszú fáradságos munkával felderítik,
hogy az összes link közül melyek mutatnak azonos inode-ra.
Pont úgy, mint az rsync.)
g
Pápai Balázs
Gábriel Ákos írta:
> On Tue, 2009-11-24 at 11:40 +0100, Zs wrote:
>
>> Igen, kérlek sorold. Különös tekintettel arra a peremfeltétlere, hogy
>> a ha egy file 15 helyen szerepel, de ez hely tekintetében egyetlen file,
>> a másik 14 pedig hardlink, akkor őszintén érdekelne, hogy a tar, cpio,
>
> Ez ugyan nem a flame, mégis talán kicsit flame-es stílusban válaszolok,
> mert az eredeti levél is olyan, de ha kipróbáltad volna a tar-t mielőtt
> pofázol, akkor rájöttél volna, hogy pl. a tar jól kezeli a hardlinkeket.
> Én kipróbáltam.
>
szellemiségénél és a flame stílust hagyjuk meg a flame listára.
Főleg, ha még a tudatában is vagyunk ennek..
Üdvüzlettel:
Pápai Balázs
listaadmin
Pirity Tamas Gabor
> Hi!
>
> >> A mentés-visszatöltést azért nem érzem egyszerűbbnek, mert mint a
> >> levél nem idézett részében említettem, nagyon sok a hardlink. Egy
> >> sima copy minden file-t át fog vinni egy példányban, így a jelenlegi
> >> 630GB pillanatok alatt 2.5-3TB lesz. Vagy rsync -a és ki tudja meddíg
> >> tart...
> >
> > Ki mondta, hogy cp-t használj?
> > Barátod a tar, cpio, afio... soroljam? :-)
> >
> Igen, kérlek sorold. Különös tekintettel arra a peremfeltétlere, hogy
> a ha egy file 15 helyen szerepel, de ez hely tekintetében egyetlen file,
> a másik 14 pedig hardlink, akkor őszintén érdekelne, hogy a tar, cpio,
> afio és egyebek hogyan oldják meg azt, hogy detektálják a hardlinket
> és a példabeli 15 file-t csak egy példányban viszik ki.
>
> Jelzem, nem véletkenül írtam rsync-et, ott ugyanis a man szerint van
> lehetőség a hardlinkek detektálására és megtartására...
>
> man rsync
> ...
> Note that -a does not preserve hardlinks, because finding
> multiply-linked files is expensive. You must separately specify -H.
Miről beszélsz?
$ echo OK > a.txt
$ ln a.txt b.txt
$ ls -il *.txt
1275610471 -rw-r--r-- 2 ptg ptg 10 nov 24 11.55 a.txt
1275610471 -rw-r--r-- 2 ptg ptg 10 nov 24 11.55 b.txt
$ echo Jó > a.txt
$ cat b.txt
Jó
$ mkdir mentes
$ cp -a *.txt mentes
$ cd mentes
$ ls -il *.txt
436824948 -rw-r--r-- 2 ptg ptg 4 nov 24 11.54 a.txt
436824948 -rw-r--r-- 2 ptg ptg 4 nov 24 11.54 b.txt
$ cat a.txt
Jó
$ cat b.txt
Jó
$ echo "Ez is jó" > a.txt
$ cat b.txt
Ez is jó
$
És ez csak a cp (GNU coreutils 6.10).
És úgy tudom, a cpio-nak is van ilyesmi kapcsolója (talán -l). És persze
még mindig ottvan az rsync.
Ha másolatot akarsz csinálni valamiről, kézenfekvő a cp-t használni.
Ha nem tudod, hogy a cp tudja-e azt, amit szeretnél, akkor célszerű
a manuálban megnézni. (Ha a kezdő listán kérdezed ezt, meg is nézik
helyetted a manban.)
--
PTG
Kilroe hic erat!
Debian Lenny
Zs
Szeretnék elnézést kérni meglehetősen udvariatlan
korábbi levelemért. Az említett programok valóban
tudják a hardlink megőrzését, ahogy azt még példával
is illusztráltátok.
Bár nem mentségnek szánom, de enyhítő körülményként
azért két dolgot megemlítenék:
- nagyon a bögyömben van ez a dolog
- a levél olvasásakor elhívtak megbeszélésre, így szokásomtól
eltérő módon ahelyett, hogy kipróbáltam volna, megelégedtem
a man oldal behívásával. Átböngészni persze ezt sem volt időm,
így a 'hard' kulcsszóra kerestem rá, feltételezve azt, hogy
lesz említés róla, hogy átviszi. Nos, egyik manuálban sincs
találat. Mivel én abból indultam ki, hogy ha ezt tudja, akkor
megemlítik, így ennek hiányából azt a téves következtetést
vontam le, hogy nem tudja.
Zsolt
Gabor HALASZ
> - a levél olvasásakor elhívtak megbeszélésre, így szokásomtól
> eltérő módon ahelyett, hogy kipróbáltam volna, megelégedtem
> a man oldal behívásával.
cp --help
Usage: cp [OPTIONS] SOURCE DEST
Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY
Options:
-a Same as -dpR
-d,-P Preserve links
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-H,-L Dereference all symlinks (default)
-p Preserve file attributes if possible
-f Force overwrite
-i Prompt before overwrite
-R,-r Recurse directories
-l,-s Create (sym)links
--
Gabor HALASZ <hala...@freemail.hu>
Pirity Tamas Gabor
> Bár nem mentségnek szánom, de enyhítő körülményként
> eltérő módon ahelyett, hogy kipróbáltam volna, megelégedtem
> a man oldal behívásával. Átböngészni persze ezt sem volt időm,
> így a 'hard' kulcsszóra kerestem rá, feltételezve azt, hogy
> lesz említés róla, hogy átviszi. Nos, egyik manuálban sincs
> találat. Mivel én abból indultam ki, hogy ha ezt tudja, akkor
> megemlítik, így ennek hiányából azt a téves következtetést
> vontam le, hogy nem tudja.
$ man cp | grep 'hard '
másolná, továbbá megőrzi az erős csatolás (hard link) kapcsola-
Erős csatolások (hard link) létrehozása a nem könyvtár
$
Az első az, ami kell neked.
--
PTG
One of the disadvantages of having children is that they eventually get old
enough to give you presents they make at school.
-- Robert Byrne
Debian Lenny