[Megoldva] Fájltörlés gyorsítása?

Ubuntu Linux

Sziasztok!

egy fájlszerveren van egy napi mentést végző script. roppant egyszerű: 5 napi mentés van, először megkeresi a legrégebbit, letörli azt, majd létrehoz egy új könyvtárat, és simán copy-val átmásolja a mentendő dolgokat. 

rm -rf `find $_dest -name "*$_day"`

mkdir "$_dest/$_path"
mkdir "$_dest/$_path/dir"

cp -a "$_src/könyvtár1" "$_dest/$_path/dir"
cp -a "$_src/könyvtár2" "$_dest/$_path/dir"
...

a forrás és a cél két külön vinyón van, mindkettő ext3 fájlrendszerrel. a mentendő adat nagyjából mindig ugyanaz, viszonlyag kevés változás van benne. tipikus méret: ~22-23k darab fájl, teljes méret ~13GB. a cél partíció jóval nagyobb, kb. 30%-ban van csak tele.

a gond az, hogy kábé 10-15 percig törli le a fájlokat, a másolás meg tart olyan 5 percig... :S szóval tetűlassú a törlés.

hogyan lehetne ezen gyorsítani szerintetek? esetleg valami más módon törölni, vagy esetleg ext3 paramétereivel játszani?

rendszer: Ubuntu 7.04 x86 (2.6.20-17-generic)

  • 1918 megtekintés

( zaphodb v | 2009. 06. 09., k – 14:13 )

nem gondolkodtál reiserfs-en?
find -exec nem gyorsabb (vagy find|xargs|rm)?
rsync?

$_day egy könyvtár. olyan könyvtárakat generál, hogy pl. 2009-06-09_kedd. a szkript megkeresi a múlt heti keddi könyvtárat és törli, majd csinál egy újat mai napra. kicsit hülye megoldás, de gyakorlatban bevált :)

----------------------------------
feel the beat - it's everywhere!

>find -exec -cel 22000x hívná az rm-et

ezt írtad. arra világítottam rá, h ha könyvtár, akkor nem 22000x.

>22000x nem tudná

hát most mittudomén milyen hosszú lehet a parancssor (getconf ARG_MAX), de könyvtárakból vszínű belefér. ugye ha csak egykarakteresek lennének, akkor talán még a 22000 is beleférhet. de ráfuthat azzal is, h nem fér bele. ez esetben rögvest 3 megoldás is akad.

>22000 egykarakteres név ez milyen lehet?

well:) csak elméleti síkon darabban gondolkodtam, azzal nem számoltam, h különbözőnek kell lennie. mondjuk ilyen a/b/c struktúrában 26*26*26*2 az több mint 22ezer, de az a/b/c az meg 5 karater, a 131ezer/5 az 26ezer és akkor a space-eket nem számoltam. természetesen arról nem is beszélve értelme nincs, mert ki mondja meg a sok a-ból, h micsoda:) de elméletileg előfordulhat, h belefér egy command line-ba ~22ezer filenév. a kínai az nagy segítség lenne darabszám szempontjából.

na ez pöpec lett! :) "leszinkronizáltam" a tegnapi backuphoz és pár másodperc alatt meg is volt. több nagyságrenddel tovább tartott átírnom a szkriptemet, mint a teljes backup. :D
köszi mégegyszer!

----------------------------------
feel the beat - it's everywhere!

mirrordir esetén milyen regexp kéne nekem (--exclude-regexp), a következőre:
a könyvtárstruktúrában szanaszét elszórva (gyak. minden alkönyvtárban van egy) vannak ilyen temp könyvtár szerűségek, amiknek mindig ugyanaz a neve, ezeket kéne kihagyni a backupból.
tehát pl. az összes létező "TempDir" nevű könyvtárat és azokban lévő fájlokat hagyja ki a mirrorból.

----------------------------------
feel the beat - it's everywhere!

mirrordirrel ez sajnos nem működik.
szerintem oda --exclude mellé csak konkrét elérési utat lehet megadni, ilyen wildcardosat nem
gondolom ezért van --exclude-regexp is, de ezt a regexpet sosem bírta kis agyam feldolgozni, pedig biztos nem bonyolult :)
csak simán egy --exclude-regexp "*/TempDir/*" jó lehet vajon?
mondjuk egyszerűbb, ha kipróbálom, igaz? :)

----------------------------------
feel the beat - it's everywhere!

( zaphodb v | 2009. 06. 09., k – 14:58 )

> a gond az, hogy kábé 10-15 percig törli le a fájlokat

btw, ez miért gond, nincs idő? :)

hát idő most még van, de később, ha nől a backup méret, akkor már neccesebb lesz az idő probléma is.
igazából csak azért érdekel a megoldás, mert windows kiddie vagyok :) és megszoktam, hogy egy ilyen könyvtárstruktúrát és 20k fájlt egy shift+delete letöröl 1 másodperc alatt ntfs-en, ext3-on meg tovább tart törölni a fájlokat mint másolni... :S

----------------------------------
feel the beat - it's everywhere!

>ext3-on

olvasgattam én is itt valami topicot amikor befellegzett a reisernek -meg amúgy is kiváncsi voltam, h muzsikál más fs-, és ott pont azt írták (épp többen), h baleset+fsck után mind reiser és xfs jobban tud adatot veszteni mint ext3, ezért erre váltottam. lassú is, fragmentálódik is meg defaultba megeszi a sok giga egy részét, gyakrabban fsckzik, ezért amint módom lesz rá lecserélem.

( tomaza | 2009. 06. 09., k – 17:45 )

http://hup.hu/node/71495#comment-778712
tehát esetedben 5 azonos méretű partíció (vagy egyszerűen fájl az ext3-on, ..felcsatova), stb

ps:persze ez csak az eredeti kérésre, tehát a törlés gyorsítására. a tényleges feladatra tényleg a szinkronizálás, azaz pl ahogy fentebb megtaláltad a mirrordirt ha működik, mert ugye az adatok nagy része nem változik, nem kell újra írni

( zeller | 2009. 06. 09., k – 17:08 )


date > _innen_/lastbackup.txt
rsync -Cavuz  _innen_  ide/$(date +"%u")/

( gee v | 2009. 06. 09., k – 17:35 )

rm -rf `find $_dest -name "*$_day"` &

és így ugyanolyan gyors lesz, mint NTFS-en ;-)

( uid_1526 | 2009. 06. 09., k – 20:06 )

rm -rf `find $_dest -name "*$_day"`

Ez a lábonlövés tipikus esete. Végignyálazod az x*22000 file-t, hogy végül megtaláld a gyökérkönyvtárat?
Helyette: 

rm -rf "$_dest"/*"$_day"

http://hup.hu/node/59173#comment-615801
:(

szerk.: egyébként maga a find _viszonylag_ gyorsan lemegy, de a törlés (rm -rf /bazi/sok/file/*) az nagyon lassú nekem, de ha gui-n csinálom (thunarból pölö), akkor meg aztán pláne :)

time find / -name "*"
real 1m23.839s
user 0m1.160s
sys 0m1.204s
(ez 342480 darab fájl)

time find / -name "*ab*"
real 0m5.147s
user 0m0.504s
sys 0m0.680s

----------------------------------
feel the beat - it's everywhere!