Dnia 06.05.2013 Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
napisał/a:
> On 2013-05-06, R.e.m.e.K <g...@d...null> wrote:
>> Dnia Mon, 6 May 2013 12:55:09 -0700 (PDT), M.M. napisał(a):
>>
>>>> A co z fragmentacja dysku?
>>> Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
>>> plików nie występuje przy spełnieniu prostego warunku: dysk nie może
>>> być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.
>>
>> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
>> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
>> Jaki nie?
>
> XFS choćby.
>
Od kiedy? Sprawdź.

xfs_bmap -v file

lub

hdparm --fibmap file

Całość

xfs_db -c frag -r /dev/sda1

Do czego służy takie "narzędzie" jak xfs_fsr?

Oczywiście fragmentuje się o rzędy wielkości wolniej niż ten wiadomy
system plików renomownej firmy.

do góry

On 2013-05-06, grapeli23 <g...@g...com> wrote:
> Dnia 06.05.2013 Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
napisał/a:
>> On 2013-05-06, R.e.m.e.K <g...@d...null> wrote:
>>> Dnia Mon, 6 May 2013 12:55:09 -0700 (PDT), M.M. napisał(a):
>>>
>>>>> A co z fragmentacja dysku?
>>>> Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
>>>> plików nie występuje przy spełnieniu prostego warunku: dysk nie może
>>>> być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.
>>>
>>> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
>>> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
>>> Jaki nie?
>>
>> XFS choćby.
>>
> Od kiedy? Sprawdź.

Odkąd został opracowany. Broni się przed fragmentacją przez alokowanie
dwa razy tego, o co do tej pory plik urósł.

Nikt nie twierdził, że fragmentacja jako taka nie występuje.
Twierdzeniem było, że fragmentacja nie jest problemem przy nowoczesnych
systemach plików.

> xfs_bmap -v file
>
> lub
>
> hdparm --fibmap file
>
> Całość
>
> xfs_db -c frag -r /dev/sda1
>
> Do czego służy takie "narzędzie" jak xfs_fsr?

Do naprawy sytuacji, w której operator był dupa i pozwolił systemowi
plików się zapełnić pod sufit. Albo do zajęcia czasu dyskowi, bo akurat
się nudzi.

> Oczywiście fragmentuje się o rzędy wielkości wolniej niż ten wiadomy
> system plików renomownej firmy.

--
Secunia non olet.
Stanislaw Klekot

do góry

Dnia 06.05.2013 Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
napisał/a:
> On 2013-05-06, grapeli23 <g...@g...com> wrote:
>> Dnia 06.05.2013 Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
napisał/a:
>>> On 2013-05-06, R.e.m.e.K <g...@d...null> wrote:
>>>> Dnia Mon, 6 May 2013 12:55:09 -0700 (PDT), M.M. napisał(a):
>>>>
>>>>>> A co z fragmentacja dysku?
>>>>> Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
>>>>> plików nie występuje przy spełnieniu prostego warunku: dysk nie może
>>>>> być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.
>>>>
>>>> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
>>>> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
>>>> Jaki nie?
>>>
>>> XFS choćby.
>>>
>> Od kiedy? Sprawdź.
>
> Odkąd został opracowany. Broni się przed fragmentacją przez alokowanie
> dwa razy tego, o co do tej pory plik urósł.
>
> Nikt nie twierdził, że fragmentacja jako taka nie występuje.
> Twierdzeniem było, że fragmentacja nie jest problemem przy nowoczesnych
> systemach plików.
>
Broń się, broń się.

do góry

W dniu poniedziałek, 6 maja 2013 23:28:02 UTC+2 użytkownik R.e.m.e.K napisał:

> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
> Jaki nie?
Nie wiem jakie systemy plikow co maja zaimplementowane, ale istnieje
algorytm bardzo odporny na fragmentacje. Poczatek pliku zaklada sie
"w srodku" najwiekszej wolnej przestrzeni. Gwarantuje to duze prawdop.
ze bedzie miejsce bezposrednio za plikiem, gdy bedziemy chcieli dopisac
dane na jego koncu. Istnieje jeszcze kilka innych technik, mysle ze
mozna poczytac i wybrac dobry system plikow dla danego zastosowania.



> Ogolna zasada budowy plikow bazy danych jest taka, ze plik jest zbudowany ze
> stron, kazda taka strona ma okreslony rozmiar i jest alokowana w chwili, gdy
> poprzednia strona sie "skonczy".
Nie wiem, ale nie sadze aby bazy dane nie oferowaly lepszych mozliwosci - co
akurat w jakims stopniu przemawia przeciwko optymalizacji recznej :)

> Juz sam fakt korzystania ze stron i ich dynamicznego przydzialu powoduje,
> ze beda one rozrzucone po dysku. Nie sadze by jakikolwiek system plikow
> gwarantowal, ze konkretnemu plikowi bazy danych da ciagly obszar dysku.
Wystarczy ze plik nie jest w ogromnej ilosci malych kawaleczkow.
Gwarancja nie jest potrzebna, wystarczy ze prawdopodobienstwo
fragmentacji jest znikome.


> Nawet gdyby tak bylo, to np. dane tabeli A moglby
> byc w stronach 2, 10, 23, 65, 127, etc. Czyli i tak nie po kolei.
Wlasnie, tak moze byc, a to jest argument za reczna optymalizacja.

> Tu masz o MS SQLu troche od kuchni. W innych serwerach jest podobnie.
> http://edu.pjwstk.edu.pl/wyklady/szb/scb/wyklad15/w1
5.htm
Dzieki.


> > Myślałem że może są jakieś zaawansowane optymalizatory.
> Optymalizatory sa, ale nie alokacji danych na dysku
Ok, o to pytalem.


> a zapytan, tworzace plan
> zapytania z uwzglednieniem indeksow (lub nawet tworzeniem ich w locie w
> razie potrzeby, jak umie czynic to MS SQL) i "inteligentnych" zlaczen.
Cos widzialem, kiedys od przypadku nawet korzystalem z jakiegos.


> Nie mozesz oczywiscie, nikt nie jest omnibusem, ale przynajmniej masz
> material do weryfikacji i przemyslen :-)
Ok, dzieki.


> Nie no.. oczywiscie. Ale nie o to mi chodzilo. Chodzilo mi o zrobienia
> enginu analogicznego do RDBMS, czyli takich "plikow CSV" i ich obslugi, ze
> mozesz dodawac miliony nowych wpisow w dowolnej kolejnosci do dowolnych
> plikow,
Moze by sie dalo, ale chodzi wlasnie o to, aby nie robic w pelni
funkcjonalnej bazy danych, tylko baze bardzo specjalistyczna i
duzo szybsza.



> laczyc podczas wyszukiwania dane z roznych plikow po jakims
> kluczu/kluczach, wyszukiwanie pozwalaloby zakladac warunki wybierajace tylko
> niektore wpisy z plikow (zlozona klauzula WHERE na kilku plikach).
> Bo jesli mowa o stalej (read only) strukturze danych, ktora jest ulozona w
> kolejnosci odczytu i odczyty sa sekwencyjne (np. 500 rekordow od setnego) to
> oczywiscie tak, mogles to napisac bez wiekszego trudu.
Nie chodzi o cos az tak prostego, ale idea jest wlasnie taka.



> > Zrób eksperyment. Załóż bazę która zawiera 5-7 tabel dużych tabel. Połącz
> > wszystkie tabele jakimiś relacjami. Napisz zapytanie do wyciągania danych.
> > Zmierz czas zapytania. Potem zapisz wyniki zapytania w pliku, w postaci
> > liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku ( w
> > jakimś dobrym języku, może Java, albo C++). Zobacz jakie będą różnice w
> > czasie.

> Ale czekaj... co znaczy "Potem zapisz wyniki zapytania w pliku, w postaci
> liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku"? Czyli
> RDBMS odwali cala robote z szukaniem, a potem mam mierzyc wczytanie pliku
> textowego z wynikami i to porownywac z baza?? Cos mi tu nie halo.
Chodzilo o cos innego, ale tak jak napisales czasami tez mozna zrobic.
Trzymamy dane w bazie i korzystamy z zalet bazy. Raz na dobe wyciagamy
dane z bazy do plikow tekstowych. Uzytkownikom podajemy dane lekko
zdeaktualizowane, ale z plikow liniowych, bez wykonywania kosztownych zlaczen.


> Lub pozwolic serwerowi zrobic indeks.
To mialem na mysli.

> Lub w sprzyjajacych warunkach (zalezy od rodzaju danych) odczytac dane
> bezposrednio z indeksu (to tez "w locie i po cichu" potrafia dobre RDBMS).
Ale to chyba tylko gdy chcemy dane z jednej kolumny? W przeciwnym razie to
by oznaczalo wlasnie taka mozliwosc o jaka pytalem, czyli sekwencyjne
ulozenie potrzebnych danych.


> Heh, myslisz, ze serwery SQL nie trzymaja ile sie da w ramie?
Chodzilo mi o przypadek, gdy RAM jest np. 100 razy mniej niz danych
na dyskach.


> To jeden z
> fundamentow wydajnosci. Nawet cale bazy potrafia trzymac jak maja odpowiedni
> sprzet (czyt. kupe ramu).
Zgoda, ale w specjalistycznym przypadku programista moze lepiej wiedziec
ktore dane i w jaki sposob buforowac w RAM.


> Zycze Ci oczywiscie sukcesow, ale imho skupiasz energie w zlym miejscu. Lub
> moze inaczej, warto sie tym zajmowac wtedy, gdy wszystko inne bedzie
> stuningowane na maksa.
Nie wiem czy w zlym miejscu. Licze ile kosztuje sprzet, ile reklamy, ile
praca... Do tego moj klient twierdzi ze 10tys uzytykownikow to jest nic...
Patrze na czasy zapytan i widze to 2 sekundy, to 10 sekund, czasami nawet
ponad 100 sekund...

10tys userow * 5sekundy * 30 odslon na jednego usera = 420 godzin na same
zapytania - jakby na odslone bylo jedno zapytanie :/


> Chodzilo mi tu o dobra, przemyslana strukture tabel i indeksow. Do
> zarzadzania plikami serwer uzywa inzynierow swojego producenta ;-)
No ale mnie to boli pomimo przemyslanych struktur tabel i indeksow :)

Pozdrawiam

do góry

W dniu poniedziałek, 6 maja 2013 23:52:47 UTC+2 użytkownik R.e.m.e.K napisał:
> Dnia Mon, 6 May 2013 21:39:36 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):

> > Swoją drogą, zupełnie nie rozumiem po co rozważać ułożenie plików na
> > dysku w kontekście webaplikacji. To jak martwić się o kolejność
> > wykonania instrukcji maszynowych dla kodu napisanego w Prologu czy innym
> > Haskellu. Ani widać wpływ drugiego na pierwsze, ani da się go w ogóle
> > mierzyć...
>
> O! To wlasnie mysl przewodnia mojego rozwleklego posta, obu nawet. Tez nie
> wiem po co to roztrzasac i szukac dziury w calym.

Przyczyna takich rozwazan jest bardzo prosta, otoz operacje dyskowe moga
byc i czesto sa waskim gardlem aplikacji webowych.

Pozdrawiam

do góry

On 2013-05-06, M.M. <m...@g...com> wrote:
> W dniu poniedziałek, 6 maja 2013 23:52:47 UTC+2 użytkownik R.e.m.e.K napisał:
>> Dnia Mon, 6 May 2013 21:39:36 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):
>
>> > Swoją drogą, zupełnie nie rozumiem po co rozważać ułożenie plików na
>> > dysku w kontekście webaplikacji. To jak martwić się o kolejność
>> > wykonania instrukcji maszynowych dla kodu napisanego w Prologu czy innym
>> > Haskellu. Ani widać wpływ drugiego na pierwsze, ani da się go w ogóle
>> > mierzyć...
>>
>> O! To wlasnie mysl przewodnia mojego rozwleklego posta, obu nawet. Tez nie
>> wiem po co to roztrzasac i szukac dziury w calym.
>
> Przyczyna takich rozwazan jest bardzo prosta, otoz operacje dyskowe moga
> byc i czesto sa waskim gardlem aplikacji webowych.

1. Jesteś pewny, że to dyskowe I/O jest wąskim gardłem u ciebie?
Szczęśliwiec. Dwie trzecie roboty już za tobą, bo namierzenie wąskiego
gardła to ta trudniejsza część.

2. Do odciążenia dysków używa się cache'u w różnych postaciach, na
przykład wstępnie przeliczonych danych w pamięci. Nie paprze się na
pojedynczych blokach na dysku, bo to zbyt pracochłonne i trudne do
zmierzenia.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 7 maja 2013 02:47:49 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:
> 1. Jeste� pewny, �e to dyskowe I/O jest w�skim gard�em u ciebie?
Pewny na 100% nie jestem, ale gdy mierze czasy zapytan, to nie widze
innej mozliwosci.


> Szcz�liwiec. Dwie trzecie roboty ju� za tob�, bo namierzenie w�skiego
> gard�a to ta trudniejsza cz��.
Moim zdaniem jest inaczej, 2/3 roboty, jesli nie 4/5, to optymalizacja po
namierzeniu waskiego gardla.


> 2. Do odci��enia dysk�w u�ywa si� cache'u w r�nych postaciach, na
> przyk�ad wst�pnie przeliczonych danych w pami�ci.
A jesli pamieci jest za malo, to zastanawiam sie, zeby czesciowe wyniki
trzymac sie w sekwencyjnych plikach dyskowych.


> Nie paprze siďż˝ na
> pojedynczych blokach na dysku, bo to zbyt pracoch�onne i trudne do
> zmierzenia.
Nie twierdze ze trzeba paprac sie az tak niskopoziomowo aby osiganac
(w miare) sekwencyjny dostep. Po prostu zapisuje sie rekord po
rekordzie na dobrym systemie plikow, a system operacyjny powinien
zapisac dane w sekwencyjnych blokach.


Pozdrawiam

do góry

W dniu wtorek, 7 maja 2013 03:16:07 UTC+2 użytkownik M.M. napisał:
> W dniu wtorek, 7 maja 2013 02:47:49 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:
>
> > 1. Jeste� pewny, �e to dyskowe I/O jest w�skim gard�em u ciebie?
>
> Pewny na 100% nie jestem, ale gdy mierze czasy zapytan, to nie widze
>
> innej mozliwosci.
>
>
>
>
>
> > Szcz�liwiec. Dwie trzecie roboty ju� za tob�, bo namierzenie w�skiego
>
> > gard�a to ta trudniejsza cz��.
>
> Moim zdaniem jest inaczej, 2/3 roboty, jesli nie 4/5, to optymalizacja po
>
> namierzeniu waskiego gardla.
>
>
>
>
>
> > 2. Do odci��enia dysk�w u�ywa si� cache'u w r�nych postaciach, na
>
> > przyk�ad wst�pnie przeliczonych danych w pami�ci.
>
> A jesli pamieci jest za malo, to zastanawiam sie, zeby czesciowe wyniki
>
> trzymac sie w sekwencyjnych plikach dyskowych.
>
>
>
>
>
> > Nie paprze siďż˝ na
>
> > pojedynczych blokach na dysku, bo to zbyt pracoch�onne i trudne do
>
> > zmierzenia.
>
> Nie twierdze ze trzeba paprac sie az tak niskopoziomowo aby osiganac
>
> (w miare) sekwencyjny dostep. Po prostu zapisuje sie rekord po
>
> rekordzie na dobrym systemie plikow, a system operacyjny powinien
>
> zapisac dane w sekwencyjnych blokach.
>
>

mozliwe ze przy takim w/ gardle
(jesli chodzi o zwykle pliki)
trzeba po prostu zarzucic
defragmentacje (programem
defrag czy czyms takim) - wtedy
lite sekwensyjne pliki faktycznie
powinny sie stac sekwencyjne

co do baz danych to faktycznie
pewnie moze to byc rozrzucone
i byc moze ten rozrzut odpowiada
za glowna czesc tych spowolnien

do góry

Dnia Mon, 6 May 2013 16:48:09 -0700 (PDT), M.M. napisał(a):

>> Ogolna zasada budowy plikow bazy danych jest taka, ze plik jest zbudowany ze
>> stron, kazda taka strona ma okreslony rozmiar i jest alokowana w chwili, gdy
>> poprzednia strona sie "skonczy".
> Nie wiem, ale nie sadze aby bazy dane nie oferowaly lepszych mozliwosci - co
> akurat w jakims stopniu przemawia przeciwko optymalizacji recznej :)

Bazy danych sa srubowane pod wzgledem wydajnosci, bo to jeden z priorytetow.
Mechanizmow temu sprzyjajacych maja wiele, w koncu to temat stary jak cale
IT, ale nie sadze by byla mozliwosc grzebania w tak niskopoziomowych
parametrach jak polozenie stron w sektorach dysku.

> Wystarczy ze plik nie jest w ogromnej ilosci malych kawaleczkow.
> Gwarancja nie jest potrzebna, wystarczy ze prawdopodobienstwo
> fragmentacji jest znikome.

Ale jesli plik baza bedzie mial kilkadziesiat GB, to podejrzewam, ze nawet
najlepszy system plikow nie zagwarantuje, ze znajdzie taki obszar w jednym
kawalku.

>> a zapytan, tworzace plan
>> zapytania z uwzglednieniem indeksow (lub nawet tworzeniem ich w locie w
>> razie potrzeby, jak umie czynic to MS SQL) i "inteligentnych" zlaczen.
> Cos widzialem, kiedys od przypadku nawet korzystalem z jakiegos.

Optymalizator jest wbudowany w engine serwera i sie korzysta z niego
wykonujac zapytania. Mozna wplynac na jego decyzje wymuszajac mu plan
zapytania, ale w dobrych serwerach wiecej takim wymuszeniem mozna zaszkodzic
niz pomoc, w gorszych (ze slabym optymalizatorem) mozna poprawic wiele.

>> Nie no.. oczywiscie. Ale nie o to mi chodzilo. Chodzilo mi o zrobienia
>> enginu analogicznego do RDBMS, czyli takich "plikow CSV" i ich obslugi, ze
>> mozesz dodawac miliony nowych wpisow w dowolnej kolejnosci do dowolnych
>> plikow,
> Moze by sie dalo, ale chodzi wlasnie o to, aby nie robic w pelni
> funkcjonalnej bazy danych, tylko baze bardzo specjalistyczna i
> duzo szybsza.

Ale jesli nie bedzie read-only to stopien komplikacji wlasnego rozwiazania
rosnie ogromnie.

>> Ale czekaj... co znaczy "Potem zapisz wyniki zapytania w pliku, w postaci
>> liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku"? Czyli
>> RDBMS odwali cala robote z szukaniem, a potem mam mierzyc wczytanie pliku
>> textowego z wynikami i to porownywac z baza?? Cos mi tu nie halo.
> Chodzilo o cos innego, ale tak jak napisales czasami tez mozna zrobic.
> Trzymamy dane w bazie i korzystamy z zalet bazy. Raz na dobe wyciagamy
> dane z bazy do plikow tekstowych. Uzytkownikom podajemy dane lekko
> zdeaktualizowane, ale z plikow liniowych, bez wykonywania kosztownych zlaczen.

Do tego mozna takze uzyc serwera SQL. Raz na dobe zrobic nim widok i go
zmaterializowac (materialized view). Efekt bedzie podobny, a roboty ZERO.

>> Lub w sprzyjajacych warunkach (zalezy od rodzaju danych) odczytac dane
>> bezposrednio z indeksu (to tez "w locie i po cichu" potrafia dobre RDBMS).
> Ale to chyba tylko gdy chcemy dane z jednej kolumny? W przeciwnym razie to
> by oznaczalo wlasnie taka mozliwosc o jaka pytalem, czyli sekwencyjne
> ulozenie potrzebnych danych.

E, czemu tylko jedna kolumne? Indeks moze obejmowac kilka kolumn.

>> To jeden z
>> fundamentow wydajnosci. Nawet cale bazy potrafia trzymac jak maja odpowiedni
>> sprzet (czyt. kupe ramu).
> Zgoda, ale w specjalistycznym przypadku programista moze lepiej wiedziec
> ktore dane i w jaki sposob buforowac w RAM.

Wiedziec a to zrobic to przepasc liczona w setkach roboczogodzin ;-)

>> Zycze Ci oczywiscie sukcesow, ale imho skupiasz energie w zlym miejscu. Lub
>> moze inaczej, warto sie tym zajmowac wtedy, gdy wszystko inne bedzie
>> stuningowane na maksa.
> Nie wiem czy w zlym miejscu. Licze ile kosztuje sprzet, ile reklamy, ile
> praca... Do tego moj klient twierdzi ze 10tys uzytykownikow to jest nic...
> Patrze na czasy zapytan i widze to 2 sekundy, to 10 sekund, czasami nawet
> ponad 100 sekund...

No i dochodzimy do meritum. Jesli zapytania wykonuja sie po kilkadziesiat
sekund to (zaznacz wlasciwe pola):
- masz spieprzona strukture logiczna bazy
- nie korzystasz prawidlowo z indeksow
- piszesz zle zapytania SQL
- uzywasz produktu serweropodobnego
- wyciagasz w wyniku miliony rekordow wraz z polami typu blob i podsystem
dyskowy nie wyrabia

>> Chodzilo mi tu o dobra, przemyslana strukture tabel i indeksow. Do
>> zarzadzania plikami serwer uzywa inzynierow swojego producenta ;-)
> No ale mnie to boli pomimo przemyslanych struktur tabel i indeksow :)

Ale wlasnie, czy aby na pewno sa one przemyslane? Czy struktura jest
znormalizowana? A jesli tak to moze zbyt znormalizowana? W praktyce dla
zwiekszenia wydajnosci stosuje sie czesto denormalizacje oraz celowa
redundancje danych. Mysle, ze struktura bazy danych moze byc tu kluczowa dla
wydajnosci, mozna nia bardzo duzo poprawic oraz ...zepsuc.

--
pozdro
R.e.m.e.K

do góry

W dniu wtorek, 7 maja 2013 01:48:09 UTC+2 użytkownik M.M. napisał:
> W dniu poniedziałek, 6 maja 2013 23:28:02 UTC+2 użytkownik R.e.m.e.K napisał:
>
>
>
> > A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
>
> > linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
>
> > Jaki nie?
>
> Nie wiem jakie systemy plikow co maja zaimplementowane, ale istnieje
>
> algorytm bardzo odporny na fragmentacje. Poczatek pliku zaklada sie
>
> "w srodku" najwiekszej wolnej przestrzeni. Gwarantuje to duze prawdop.

to bylby wlasnie chyba najszybszy
sposob na zajechanie dysku, wrzucasz
np na dysk 1 tys empetrójek i masz
dysk pociety na 1000 kawalków

z defragmentacją latwo poradzic sobie
w ten sposob ze odpala sie program
defrag, jakby te programy byly
inteligentne to przenosilyby na
poczatku wlasnie te male pliki
ktorych przeniesienie zwolni
najwieksze 'bloby' jesli tak to
mozna nazwac

do góry