Poziom fragmentacji wynosi 4,2%. System plikow ext3. Partycje te sa w uzyciu przynajmniej od 5 lat.

Tylko raz spotkalem sie z serwerem LMS, postawionym na sprzecie IBM gdzie poziom fragmentacji wynosil 72%. Powodem bylo podlaczenie przez administratora dodatkowego dysku na backup-y, ktory automatycznie przy starcie systemu zostal hardware-owo ustawiony na RAID z mirroringiem, co doprowadzilo w konsekwencji do problemow przy synchronizacji dyskow. Jak wiadomo lepiej na linuksie robic takie rzeczy programowo… a jak ktos nie wierzy to niech sie sam przekona- chociaz moze to byc bolesne doswiadczenie ;)

Spróbuj wyłączyć automatyczną defragmentację – podejrzewam, że fragmentacja plików zdrowo wzrośnie.

Kiedyś w XP "urwało" mi nagrywanie płyty CD na prędkości 8X – jak się okazało zbyt duża fragmentacja i bufor nie wyrobił.

Pod EXT3 z pełnym księgowaniem na 40GB nie miałem fragmentacji powyżej 1,8% (po instalacji i ustawieniu journal_data 0,8%) O_o – cały korzeń systemu był na jednej partycji a system używany był do przeglądania stron oraz pracy na Open Office.

Fragmentacja w EXT-FS jak i w ReiserFS była i będzie, zazwyczaj jest ona jednak bardzo mała, wręcz pomijalna. Nawet przy intensywnym korzystaniu z dysku poziom fragmentacji będzie bardziej niż akceptowalny, zauważcie, że niewiele osób poza wklepaniem "e2fsck -D /dev/hdxx" cokolwiek więcej z tym robi. "Fragmentacja jest czy jej nie ma?" – przypomina mi to kłótnie o wirusy na Linuksa – niby są a jednak.. ;).

Teraz używam JFS i jestem zadowolony, a zdanie "zainstaluj i zapomnij" bardzo mi tu pasuje.

Naprawdę miło jest czytać TAKĄ dyskusję.

Pozdrawiam ;)

from: can't read /var/mail/optparse

ok_defrag: 7: Syntax error: "(" unexpected

Prosze o pomoc

Partycje zajęte są od roku, system używany w domu dość intensywnie.

System to ReiserFS, rozmiar 1GB, zapełnienie 25%, wiek 2-3 lata.

Jeżeli komuś bardzo zależy na defragmentacji, to polecam Shake — http://vleu.net/shake/

Poszukaj opcji w rodzaju "Allocate and zero new files on creation" (ofc w innym kliencie nie musi nazywać się tak samo).

<code>

df -h | grep sda2

/dev/sda2 19G 4.5G 14G 26% /

</code>

<code>

sudo fsck.ext3 -nfv /dev/sda2 :

213818 inodes used (17.47%)

1369 non-contiguous inodes (0.6%)

# of inodes with ind/dind/tind blocks: 9534/98/0

1210104 blocks used (24.77%)

</code>

<code>

df -h | grep sda5

/dev/sda5 58G 45G 14G 77% /hda5

</code>

<code>

sudo fsck.ext3 -nfv /dev/sda5 :

10623 inodes used (0.14%)

83 non-contiguous inodes (0.8%)

# of inodes with ind/dind/tind blocks: 1762/141/1

11867868 blocks used (77.08%)

</code>

<code>

df -h | grep home

/dev/mapper/home 111G 97G 8.0G 93% /home

</code>

<code>

sudo fsck.ext3 -nfv /dev/mapper/home

144897 inodes used (0.99%)

5643 non-contiguous inodes (3.9%)

# of inodes with ind/dind/tind blocks: 18057/3893/1

25748584 blocks used (87.88%)

</code>

wiec jak z ta fragmentacja ? jak widac w rzeczywistosci jest NIEWIELKA (c.b.d.u)

To rozwiązanie oczywiście też jest dobre i daje lepsze rezultaty, jednak nie zawsze jest możliwe np. jak masz dużą ilość danych.

Dla Ext4 powstaje profesjonalny program do defragmentacji, więc problem zostanie w miarę szybko rozwiązany.

Nie spodziewałem się tak pozytywnego wyniku po systemie, który ma prawie 2 lata i jest ostro katowany czy to dużymi, czy małymi pliczkami.

Natomiast problem fragmentacji faktycznie kiedyś się może pojawić. Pytanie natomiast, czy nie jest najprościej pozbyć się jej, robiąc po prostu "tar -czpvf archiwum.tar.gz /", "rm -rf /", a potem rozpakowanie tego systemu ponownie… (oczywiście, pakując na inną partycję i z live'a ją przywrócić)…

Ale miałem na myśli błędy poleceń, już lepsze było by użycie getstatusoutput() który zwraca status. Ale jak już jesteśmy przy błędach I/O no to trzeba było użyć C a nie Pythona i byłbyś maksymalnie blisko systemu.

IMO chybiony argument. Taki sam problem może występować w setkach tysięcy skryptów shellowych – jakoś to ludziom nie doskwiera.

"2. Nie mamy kontroli nad błędami (których w ogóle nie sprawdzasz)."

Sprawdzanie błędów które są ważne np. błędy i/o jest na poziomie sum kontrolnych – według mnie jest to skuteczniejsza metoda niż poleganie na pythonowym except.

"Poza tym czym różni się ok_defrag od defrag CK"

Widzę, że przejrzałeś tylko kod – sposobem układania danych oraz zastosowaniem sum kontrolnych do sprawdzania poprawności plików (dzięki temu zawsze zostaje poprawna kopia pliku).

1. Format zwracanych danych może różnić się między wersjami tych poleceń i może to prowadzić do nieokreślonych skutków.

2. Nie mamy kontroli nad błędami (których w ogóle nie sprawdzasz).

Poza tym czym różni się ok_defrag od defrag CK? Oprócz tego że jest w Pythonie w którym wołasz te same polecenia nie sprawdzając nawet statusu zakończenia (co w oryginalnym skrypcie jest).