Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Tutorial Jak powiększyć przestrzeń wymiany
#21
0
(19-03-2019, 20:43)morfik napisał(a): Maszyny (i Morfik) są innego zdania. Big Grin

Nie zgadzasz się z definicją fragmentacji? Dla ciebie na pewno ją zmienią.[Obrazek: biggrin.png]
Odpowiedz
#22
0
Nie podszczypywać mi się tutaj. Tłumaczyć jak krowie na rowie co i jak. Dobrze, że jesteście na forum bo można się od was sporo nauczyć ... ale nie brnijmy w kierunku kto ma większe cojones, a każdy na tym skorzysta Big Grin

Edit:

Zacny Sufler mi podrzucił link:


Cytat:Extents

Extents replace the traditional block mapping scheme used by ext2 and ext3. An extent is a range of contiguous physical blocks, improving large file performance and reducing fragmentation. A single extent in ext4 can map up to 128 MiB of contiguous space with a 4 KiB block size.[4] There can be four extents stored directly in the inode. When there are more than four extents to a file, the rest of the extents are indexed in a tree.[13]
Źródłohttps://en.wikipedia.org/wiki/Ext4#Features

Morfik tobie o to biega?
Odpowiedz
#23
1
Better response on post RE: Jak powiększyć przestrzeń wymianyNo przecie cały czas piszemy o zakresach bloków. Big Grin

Definicja fragmentacji jest prosta -- jeśli plik jest przechowywany w systemie plików w częściach, to jest on pofragmentowany, nie ma znaczenia przy tym surowy odczyt bajtów na nośniku, bo między brzegiem płyty talerza, a głowicą magnetyczną, jest jeszcze warstwa logiczna, której zastosowanie uniemożliwia odczyt/zapis sekwencyjny większej ilości danych, przynajmniej w EXT4. A nie dasz rady odczytać/zapisać pliku 128M+ na EXT4 bez wykorzystywania kolejnych zakresów, więc w EXT4 masz pliki, których rozmiar fragmentów nie może przekroczyć 128M. Więc jeśli coś ma fragmenty, nawet takie duże, to i tak jest pofragmentowane. Big Grin Ktoś mi kiedyś powiedział, że w zasadzie to mniejsze znaczenie ma to gdzie części pliku na dysku się znajdują, a o wiele większe znaczenie ma fakt, że plik ma w ogóle części. Big Grin Zapewne wynika to z faktu, że gdy system skończy czytać 128M i musi odpytać system plików o kolejne dane, to głowica przez powstałe opóźnienia w tym czasie nie odczyta obszaru 128M+1bajt(i następne) i głowicę będzie trzeba na nowo wypozycjonować, a to wiąże się z kolejnymi opóźnieniami, zwłaszcza, gdy w kolejce do odczytu/zapisu były jakieś inne pliki, np. logi systemowe i czytanie SWAP z systemowego dysku może dość znacznie spowolnić używanie kompa, bo co jak co ale dysk systemowy zwykle nonstop coś zapisuje/doczytuje, a im jest on bardziej obciążony, tym drastyczniej się to odbija na wydajności przy korzystaniu jeszcze dodatkowo ze SWAP (nie tylko pliku). Jak do tych wszystkich negatywnych czynników dojdzie jeszcze fragmentacja plików, to zamiast 120M/s raw (czytając surowe urządzenie np. /dev/sda od początku dysku), to otrzymuje się 20-40M (czasami nawet i mniej) i tu już masz zajebistą utratę wydajności.  Big Grin  No ale działa, a przecie o to przeciętnemu kowalskiemu chodzi.
Odpowiedz
#24
0
Czy ktoś przeczytał tą ostatnią wiadomość do końca? Czy mógłbym prosić o jakieś streszczenie?[Obrazek: biggrin.png]
Odpowiedz
#25
0
@magnus W jakiej kwestii się nie zgadzasz? Brzmi logicznie. Argumenty proszę na nie Exclamation

Prosiłem już kogoś nie z tego forum (starozakonny) o konsultacje i nie było uwag.

My w tym dziale [TUTORIALE] się mamy wzajemnie uczyć i inspirować Rolleyes



Jak ktoś nie czai o co chodzi, to chłopaki różnią się w poglądach co do postu https://forum.linuxmint.pl/showthread.ph...670#pid670

Kod:
$ sudo filefrag -ve /swapfile
Filesystem type is: ef53
File size of /swapfile is 1439201280 (351368 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  253951:     264192..    294911:  30720:            
   8:   253952..  286719:     296960..    329727:  32768:     294912:
   9:   286720..  319487:     329728..    362495:  32768:            
  10:   319488..  351367:     362496..    394375:  31880:             last,eof
/swapfile: 5 extents found


Chodzi i liczbę wierszy w pierwszej kolumnie ext w zakresie 0:-10: (11) , podsumowanie /swapfile: 5 extents foundoraz kolumnę expected: .

Cytat:Program filefrag najpierw stara się  pozyskać  informację  o  ekstencie  za  pomocą  ioctl

FIEMAP,  które  jest  znacznie  wydajniejsze  i  szybsze.  Jeśli  FIEMAP jest niedostępne,

korzysta z FIBMAP.

-e     Wypisuje wynik w formacie ekstentów, nawet w  przypadku  plików  przydzielonych  do

             bloków.

-v     Wypisuje więcej informacji przy sprawdzaniu fragmentacji pliku.
 Źródło: man filefrag - http://manpages.ubuntu.com/manpages/bion...rag.8.html
Odpowiedz
#26
0
@ciastek1981 Argumenty już przedstawiłem. Jeśli kogoś nie przekonałem to powtarzanie ich nie ma sensu.

Z podręcznika programu filefrag:

Cytat:Program filefrag informuje o poziomie fragmentacji danego pliku.

Który wynik powinniśmy uznać za fragmentację pliku? Wykonajmy komendę filefrag bez dodatkowych opcji, niech program poinformuje nas jedynie o poziomie fragmentacji:

Kod:
$ sudo filefrag /swapfile
/swapfile: 5 extents found

Ostatecznie, który wynik uznamy za fragmentację nie ma większego znaczenia. Nasza dyskusja wykazała że użycie plików wymiany jest w pełni uzasadnione. Żeby utrzymać fragmentację na niskim poziomie warto co pół roku zrobić pełną instalację systemu.
Odpowiedz
#27
0
A ja tam wolałem zagadać z ludźmi, którzy tworzą ext4 i się ich zapytać jak to dokładnie jest z tą fragmentacją. No ale tutaj widać ludzie nie lubią czytać zbyt długich postów, zatem podsumuję tamtą dyskusję tymi słowami: "to bardziej skomplikowane" -- mam nadzieję, że teraz już jest wszystko jasne. xD
Odpowiedz
#28
0
To ja mam tylko pytanie dla rozjaśnienia jeżeli uzyskujemy wynik z polecenia filefrag z parametrami, to z czego wynika różnica extentsw  kolumnie ext: i /swapfile: X extents found ? Jak dla tumana proszę Big Grin
Odpowiedz
#29
0
Plik jest zakodowany w systemie plików jako osobne kawałki (widziane w kolumnie ext). Logicznie (nie "na logikę") mamy zakresy 0, 1, 2, itp. -- generalnie jest tyle tych kawałków ile widać w kolumnie ext. Jeśli kilka z tych logicznych kawałków znajduje się obok siebie, to mamy ciągły obszar danych na dysku. Co jest póki co logiczne (na logikę) i dlatego napisałem, że z perspektywy maszyny są to osobne kawałki, a dla człowieka takie fragmenty 128M jeden za drugim mogą być traktowane jako jeden. Niemniej jednak, nawet ciągły obszar jest czytany przez system w kawałkach, z racji budowy komputera i ogólnie systemu operacyjnego (wiele procesów próbuje zapisywać/odczytywać dysk w tym samym czasie, a tylko jeden proces w danym konkretnym momencie może to zrobić). Zatem nawet jeśli plik ma wiele ciągłych bloków danych na dysku, to mogą w systemie zajść zdarzenia (i to jest zwykle pewnik), które uniemożliwią czytanie tego pliku w pojedynczej operacji I/O. Zatem nawet jeśli plik będzie miał jedną ciągłą część, a zostanie odczytany na raty w 20 operacjach, to z perspektywy tej konkretnej operacji odczytu, plik można traktować tak jakby miał 20 części i w zasadzie to w ilu częściach figuruje na dysku nie ma w tym konkretnym przypadku żadnego znaczenia. Big Grin Generalnie chodzi o transfer danych pojedynczej operacji, który nie jest jakoś specjalnie duży przy operowaniu na plikach. Zatem jeśli nawet można by plik odczytać szybciej, to pewnie procesor się zagotuje i transfer danych z dysku zostanie wstrzymany i trzeba będzie kolejną operację I/O przeporwadzić i odczytać kolejną część pliku. To co z kolei jest ciekawe, to że ext4 ma cache wszystkich zakresów pliku, który sobie tworzy w pamięci RAM przed dokonywaniem faktycznych operacji I/O . Zatem teoretycznie możliwe jest nawet odczytanie całego pliku, np. 10G, w jednym podejściu (jedna operacja I/O) mniej więcej tak samo jak przy odczycie surowym np. przez dd if=/dev/sda , no bo lokalizacja wszystkich bloków jest już znana i nie trzeba wykonywać dodatkowych zapytań do dysku, by poznać lokalizację następnych bloków danych, przez co z kolei głowica dysku może przejść płynie do następnego zakresu (to był jeden błąd we wcześniejszej wypowiedzi Big Grin). Czyli sam system plików jako taki nie wywołuje dodatkowych opóźnień (tak jak myślałem wcześniej) w stosunku do surowego odczytu danych z nośnika, oczywiście jeśli mamy do odczytu kolejne ciągłe bloki danych.  I teraz wypadłoby zestawić tę wiedzę z ilościami zapytań do pliku wymiany. No jakby nie patrzeć, przy dość sporym wykorzystaniu SWAP, tych operacji będzie bardzo dużo ale zwykle jedynie małe porcje danych będą doczytywane/zapisywane -- nie będzie sytuacji w których system będzie próbował odczytać/zapisać naraz 1G danych. Dlatego też w tym przypadku (i w wielu innych) wpływ fragmentacji pliku SWAP na wydajność systemu nie powinien być w zasadzie nawet do zmierzenia. Big Grin
Odpowiedz
#30
0
Wygląda na to że wszystkie spory pod tym poradnikiem były niepotrzebne, nic nie wniosły do jego treści. Obudziły jedynie wątpliwości, pewnie nie tylko u mnie, czy warto poświęcać czas i pisać cokolwiek.
Odpowiedz


Skocz do:




Użytkownicy przeglądający ten wątek: 2 gości