Šta je novo?
Od:
Filteri

Linux online defrag - iskustva?

A

Ace Rimmer

Slavan
VIP član
Učlanjen(a)
31.12.2005
Poruke
2,826
Poena
380
Probao neko na iole većem file sistemu? XFS ili EXT4?
Malo sam se jučer igrao sa e4defrag na pojedinačnim fajlovima i čini se ok (Fedora 17, 3.4 kernel).
Zadnji put kad sam tražio iskustva sam iskopao slučaj da je neko radio defrag XFS particije s gigabajtima mp3-ica ... ispala je mp3 salata, doslovno :d.
 
Ne zezaj da Linux DANAS nema online defrag koji radi? :D
 
Sta ti filefrag kaze ? Da li ti zaista treba defragmentacija ?
 
Ne treba mi realno, zanima me samo da li je funkcionalno? :p
 
Nikada do sada nisam imao problem sa fragmentaciom na ext* FS. Dokle god je /var na posebnom LVM-u i ne koristis vise od 80% prostora FS-a ne bi ni trebao da imas problema.

Jednom sam imao problem sa GFS2 sto se tice fragmentacije. Bio je neki KVM cluster i na GFS2 su se drzale virtualne masine, odjednom je jedna VM znatno usporila sa radom, tu je filefrag pokazao da je zapravo fragmentacija problem. Prosto prosirivanje (C)LVM na kome je bio taj GFS2 i premestanje image-a te VM prvo na drugi FS pa onda njegovo vracanje na GFS2 je resilo problem.
 
Mislim da ti na ext3/4 nije potreban defrag. Sta vise, nisam bas cuo da neko ima problema sa fragmentacijom na linuxu, dok god imas dovoljno slobodnog prostora.
 
A kako to radi, Idle defrag?
 
Nisam bas stucno upucen (pa me ispravite ako grijesim), ali iz onog sto sam citao po netu, narodski receno, jedan od razloga je to sto ext fajl sistem "pazi" da prilikom upisa fajlovi budu sto manje fragmentisan, na primjer tako sto fajlove ne upisuje sekvenciono vec koristi cijeli raspolozivi prostor, te ostavlja dosta prazanog izmedju fajlova, sto omogucava da im se sa istim dalje manipulise bez fragmentacije.
Zbog toga je preporucljivo da se diskovi ne pune do kraja.
 
Ako je to tako kako @farmaceut pise sta se time dobija? Dobija se upisan fajl koji nema ekstente, fajl u jednom komadu ali? Sta je sa praznim prostorom izmedju fajlova, to ne valja iz prostog razloga sto ce glava-e diska da setaju ko lude a taj prazan prostor je fragmetacija diska. Sad se tu najverovatnije manipulise tako sto se sve zivo sto moze i treba trpa u memoriju da bi se izbeglo cesto pristupanje disku.
Mozda se radi i preload, swap se skoro i ne koristi i predpostavljam da bi koriscenje swap fajla drasticno usporilo sistem. Najbolji pokazatelj je ucitavanje nekog fajla koji nije dugo pozivan, to moze da potraje dok ga nadje i ucita a to meni lici da ipak radi neki defrag koji premesta fajlove koji se ne koriste na kraj diska. Jos jedna opasna cinjenica je resize particije na manje, ako su fajlovi tako nabacani a neku pogolemi file je na kraju particije sta ce biti sa njim?
 
Logicno je da je ovo dobro na pocetku, ali sumnjam da pri cestom pisanju/brisanju previse pomogne, posto nisu svi fajlovi slicnih velicina pa da moze neka super-cluster ideja (naspram obicnog clustera sektora) da se primeni.

U prevodu, ako bi Linux radio podjednako kao Winodws koliko bi bio fragmentovan?
 
@lega99: Ovo sto sam iznjeo je po mom sjecanju sto sam nekad davno citao, te mozda i nije poptuno tacno. Vjerovatno na netu ima sve detaljno objasnejno.
 
U prevodu, ako bi Linux radio podjednako kao Winodws koliko bi bio fragmentovan?
Kliknite za proširenje...

Vjerovatno puno manje. I mog iskustva, linux nikad nisam defragmentovao u zadnje 3-4 godine koliko ga koristim na desktopu, niti sam vremenom imao neka znacajna usporenja u radu sa fajl-sistemom.

Drugo je pitanje, zasto traziti "analogiju" izmedu dve razlicite platforme? Ako je za Win karakteristicno da se "fragmentuje", da je "must have" imati antivirus/malware/spyware/firewall i sl., ne treba analogiju traziti i na Linuxu, gdje to prakticno ne postoji. (ok, postoji, ali ne dotice obicne korisnike)

Isto vazi i obrnuto, za Linux je cesto prava glavobolja instalirati neki Radeon XXX 3D driver ili kompajlirati neki egzoticni drajver za wireless karicu (oba primejra su meni oduzela po godinu dana zivota :), a sto je na Win podrazumjevano u dva klika "next..next..."

Jednostavno, drugacije filozofije i takao ih treba prihvatiti.... te uzivati u blagodetima i jednih i drugih, shodno potrebama...
 
alfaunits je napisao(la):
Logicno je da je ovo dobro na pocetku, ali sumnjam da pri cestom pisanju/brisanju previse pomogne, posto nisu svi fajlovi slicnih velicina pa da moze neka super-cluster ideja (naspram obicnog clustera sektora) da se primeni.
Kliknite za proširenje...
Navodno se fragmentira dosta u sličnim uvjetima.
Razlika je u veličinama file sistema s obzirom na (desktop)Windows i tendenciju da se Linux file sistemi proširuju/nadograđuju po potrebi pa problem ne dolazi do izražaja.
 
Poslednja izmena:
farmaceut je napisao(la):
Vjerovatno puno manje. I mog iskustva, linux nikad nisam defragmentovao u zadnje 3-4 godine koliko ga koristim na desktopu, niti sam vremenom imao neka znacajna usporenja u radu sa fajl-sistemom.

Drugo je pitanje, zasto traziti "analogiju" izmedu dve razlicite platforme?
Kliknite za proširenje...

Ne poredim Linux i Windows, beskorisno je. Poredim same file systeme, jer me zanima.
Zasto porediti ISTI tretman file systema? Pa da bi se videlo da li je file system optimizovaniji ili je u pitanju razlicita upotreba. Ako je razlicita upotreba, onda nije fora da "ext3/4 ne treba defragmentovati" vec "tipicno koriscenje Linuxa ne zahteva defragmentaciju ni priblizno kao tipicno koriscenje Windowsa". Ovo drugo... je poredjenje baba i zaba, zato me zanima da li je ovo prvo u pitanju.
Jer ako je prvo, onda moze mnogo toga da se nauci iz implementacije Ext3/4 i prenese u Windows. Ali ako je ovo drugo, onda nije to prednost file systema nego nacina upotrebe istog.


Zamisli to ovako... pravis SSD kontroler. Da li te zanima da li se neki file system fragmentuje ili te zanima da li se hardverski fragmentuje NAND? Ovo prvo tebe ne treba da zanima kao dizajnera SSD kontrolera kao stavka. Ali kako ti to vidis na NAND nivou treba.
Otprilike :)
 
Hoce da kaze da ako se file povecava i povecava, NTFS ga, na MALTENE praznom volume-u razbacuje po celom disku??
Ako Ext4 ne menja alokacije dinamicki (menja pozicije podataka, tj. pomera file na disku), ne znam kako bi mogao da ga zadrzi u malom broju segmenata naspram drugih FS-a?
 
Ako se file povecava ekstenti se upisuju najverovatnije na prvom praznom prostru koji ispunjava uslov (NTFS), ne verujem da je file sistem pravio neki idot pa onako od frlje upise ekstent na kraj diska .
Ext4 najverovatnije ima neki algoritam po kojem pokusava da sastavi file iz jednohg komada, upise ekstent a onda u nekom trenutku to sve sastavi i prebaci na dovoljno veliki kontinuirani prostor.
Jos jedna cinjenica u koju nisam mogao da poverujem, tek sa pojavom ext4 fajl sistema belezi se datum kreiranja fajla. U te testove vise ne verujem, ATA (PATA) i sad odjednom SATA je brza, zasto, najverovatnije zbog baferovanja i preloada, toliko godina zablude i onda je neko otkrio Ameriku, malo to deluje onako neverovatno.
 
lega99 je napisao(la):
Ako se file povecava ekstenti se upisuju najverovatnije na prvom praznom prostru koji ispunjava uslov (NTFS), ne verujem da je file sistem pravio neki idot pa onako od frlje upise ekstent na kraj diska .
Kliknite za proširenje...
Ako je kopirano 7GB fajlova, oni su sigurno kontinualni, pa nema razbacanog praznog prostora.

Ext4 najverovatnije ima neki algoritam po kojem pokusava da sastavi file iz jednohg komada, upise ekstent a onda u nekom trenutku to sve sastavi i prebaci na dovoljno veliki kontinuirani prostor.
Kliknite za proširenje...
To vec ima logike kao nacin da se smanji fragmentacija, i bash je ono na sta ciljam - Idle time defrag u samom file system-u. Ali ako to radi tokom upisivanja samog fajla, onda bi to enormno usporilo sistem.

Moguce je i da su cache manageri toliko razliciti na ova dva OS-a... na Windowsu kada se upisuje file, osim ako aplikacija namerno ne radi uncached write, prvo ce se podosta nakupiti u cache manager-u, pa tek ce se onda stvarno upisati. Tada FS ima vremena da alocira sve sto ce iz CM-a tek stici, jer pre nego sto dobije same upise za disk, FS vec zna da je file veci nego sto je trenutni upis iz CM-a.
Ne znam kako to radi na Linuxu, ali ovo je dobar nacin da FS sam alocira vece delove. Kad sam radio nas cluster FS, CM je dakle omogucavao da FS alocira delove od po 100-ak MB pa i vise (zavisi od slobodne memorije, u to doba je vec GB bio ihaha) odjednom.

Sam test mi izgleda cudno bash zbog toga.
 
Pretpostavljam da je bitno i kako je podešen konkretni EXT file sistem, može biti da i to utiče na fragmentaciju. Znači, da li će se zapisivati često, ili postoji keširanje i out-of-order zapisivanje (to opet ovisi od distribucije do distribucije).
Zgodan članak (koji se doduše bavi nekom drugom problematikom vezanom za EXT3 vs EXT4):
http://blog.nirkabel.org/2008/12/07/ext3-write-barriers-and-write-caching/
 
Evo bash gledam Wiki za Ext4... evo neke stvari koje def. dobro uticu na smanjenje fragmentacije:
Delayed allocation, Extents (ovo je izgleda bas super-cluster)
Mislim da NTFS ne radi delayed allocation, barem ne bez CM-a. Na Linuxu je izgleda CM vezan za sam FS a ne sistem. (mozda lupam, ali ne vidim kako bi Ext4 mogao da uradi delayed alloc ako ne saceka upise, tj. cuva ih u memoriji)

I barem po Wiki, Ext3 ne podrzava Create date.... LOL
 
Poslednja izmena:
alfaunits je napisao(la):
I barem po Wiki, Ext3 ne podrzava Create date.... LOL
Kliknite za proširenje...

Valjda tako treba biti ;). Od iole aktualnih Linux FSova imaju samo Btrfs i Ext4. Od starijih ima samo JFS.

There is no such thing as a "creation date" in unix/linux.
Commonly people misinterpret the "ctime" field as having something to do
with "creation", but actually the C stands for "inode change".
Hence the ctime will be updated if you change the owner of a file, or
make a hard link to the file; anything that changes the information in
the inode.
Kliknite za proširenje...
http://lists.samba.org/archive/rsync/2008-April/020746.html
 
Poslednja izmena:
Morate se prijaviti ili registrovati da odgovorite ovde.
Vrh Dno