Dyskusja o poradniku "Czyszczenie systemu"

[morfik]

0

Ze względu na sposób formatowania twardych dysków i napędów półprzewodnikowych (SSD) Linux Mint bardzo dobrze radzi sobie z fragmentacją pamięci, zwłaszcza jeżeli dana partycja jest przynajmniej w 20% wolna. Dlatego nie stosuje się defragmentacji, tym bardziej że może to doprowadzić do utraty plików.

Co ma dystrybucja do radzenia sobie z "fragmentacją pamięci"? No i też od kiedy defragmentacja powoduje utratę plików? Ja o czymś nie wiem?

[magnus]

0

>> Czyszczenie systemu

Co ma dystrybucja do radzenia sobie z "fragmentacją pamięci"?

System plików ma, ext4 vs. NTFS.

No i też od kiedy defragmentacja powoduje utratę plików?

Defragmentacja to przemieszczanie fragmentów plików. Jeżeli zrobisz to źle to je utracisz.

[morfik]

0

No to już nie "dystrybucja", a "system plików" ale nawet i ten ext4 pozostawia wiele do życzenia bo system nie potrafi wgrać pliku 1 GiB na pustą partycję 1TiB w jednym kawałku... a kolejne dogrywanie plików sprawia, że może być już tylko gorzej.

Defragmentacja to nie przemieszczanie fragmentów plików, a przemieszczanie całych plików. Do tego ta operacja jest przeprowadzana synchronicznie (z pominięciem buforów pamięci, cache, itp). Krótko mówiąc, jeśli chcesz zdefragmentować plik, który ma 1 GiB, to pierw potrzebujesz 1 GiB wolnych bloków na dysku (by przenieść dane ze starych bloków do nowych). Dopiero jak ta operacja zostanie zakończona sukcesem, i-wezeł jest aktualizowany. Możesz w ostatniej chwili wcisnąć ctrl+c w terminalu i przerwać proces defragmentacji pliku, i żadne zmiany nie zajdą, bo i-węzeł dalej będzie powiązany ze starymi blokami. To jest mniej więcej tak jak wycinanie i wklejanie pliku -- chyba nie powiesz ludziom, by nie kopiowali/przemieszczali plików, bo może to powodować utratę danych?

[magnus]

0

Ze względu na sposób formatowania twardych dysków i napędów półprzewodnikowych (SSD) Linux Mint bardzo dobrze radzi sobie z fragmentacją pamięci, (...)

Co ma dystrybucja do radzenia sobie z "fragmentacją pamięci"?

Gdzie tu pisze że to dystrybucja? Nie rozumiesz zwrotu: "Ze względu na sposób formatowania ..."?

Defragmentacja to nie przemieszczanie fragmentów plików, a przemieszczanie całych plików. (...) jeśli chcesz zdefragmentować plik, który ma 1 GiB, to pierw potrzebujesz 1 GiB wolnych bloków na dysku (by przenieść dane ze starych bloków do nowych).

Według tego co piszesz to fragmenty plików ze starych bloków są przemieszczane w nowe miejsce gdzie są składane w jedną całość...

(...) ext4 pozostawia wiele do życzenia bo system nie potrafi wgrać pliku 1 GiB na pustą partycję 1TiB w jednym kawałku...

...chyba że się pogubią. 

To jest mniej więcej tak jak wycinanie i wklejanie pliku -- chyba nie powiesz ludziom, by nie kopiowali/przemieszczali plików, bo może to powodować utratę danych?

To jest poradnik dla początkujących którzy pierwszy raz próbują Linuksa. Jest ryzyko że będą próbowali zbędnej defragmentacji za pomocą programów znalezionych w internecie.

Ze strony: >> Easy Linux Tips Project

Uwaga: Niestety, niektóre narzędzia do defragmentacji można znaleźć na obrzeżach ekosystemu Linuksa. Nie używaj ich! Istnieje spore ryzyko, że albo zepsują one twój system nie do naprawienia, albo spowodują masową utratę plików. To niebezpieczne bzdury. Bez żadnego wyjątku.

[morfik]

0

Nie rozumiesz zwrotu: "Ze względu na sposób formatowania ..."?

No właśnie nie rozumiem.

Defragmentacja to nie przemieszczanie fragmentów plików, a przemieszczanie całych plików. (...) jeśli chcesz zdefragmentować plik, który ma 1 GiB, to pierw potrzebujesz 1 GiB wolnych bloków na dysku (by przenieść dane ze starych bloków do nowych).

Według tego co piszesz to fragmenty plików ze starych bloków są przemieszczane w nowe miejsce gdzie są składane w jedną całość...

W jaki sposób wywnioskowałeś to z tego co napisałem wyżej? Proces defragmentacji nie składa nic w jedną całość! Albo ma dostatecznie dużo wolnej przestrzeni by umieścić plik w jednym kawałku kopiując go ze starych bloków, albo nie ma. Cała filozofia...

To jest poradnik dla początkujących którzy pierwszy raz próbują Linuksa. Jest ryzyko że będą próbowali zbędnej defragmentacji za pomocą programów znalezionych w internecie.

Co ma za znaczenie dla kogo jest dany poradnik -- albo piszesz fakty albo farmazony. Jedyna różnica jest taka, że jeśli ktoś nie ma wiedzy technicznej w danym zakresie to może przyjąć na wiarę to co w takim poradniku wyczytał i później się takiemu komuś nie da tego z głowy już wybić.  I co rozumiesz pod pojęciem zbędna defragmentacja?

Ze strony: >> Easy Linux Tips Project

Uwaga: Niestety, niektóre narzędzia do defragmentacji można znaleźć na obrzeżach ekosystemu Linuksa. Nie używaj ich! Istnieje spore ryzyko, że albo zepsują one twój system nie do naprawienia, albo spowodują masową utratę plików. To niebezpieczne bzdury. Bez żadnego wyjątku.

Przeczytałem kawałek tego linku -- ten kto to pisał wykazał się niesamowitym brakiem wiedzy z zakresu systemu plików. Dlaczego? Chłopaki, system plików ext4 ma natywne narzędzie do defragmentacji -- e4defrag . Używam go od momentu kiedy przesiadłem się z ext3 na ext4, czyli ponad dekadę. Jakoś danych żadnych nie straciłem... a defragmentuje swoje HDD regularnie.

Chciałem to wypunktować po kolei ale już naprawdę mi się nie che walczyć z wiatrakami Podam tylko jeden przykład by wykazać, że ten link co podałeś można sobie wsadzić nie powiem gdzie, i upchnąć jeszcze głębiej Czytamy w nim:

How can I defragment the hard drive in Linux?
4. A Linux partition doesn't need to be defragmented at all. Because Linux has been built to prevent fragmentation: only insignificant fragmentation can arise, as long as the partition has more than 20% of free space.

Jak widzimy na przykładzie jednej z moich partycji:

Kod:

# df -h /media/Arti
Filesystem                     Type  Size  Used Avail Use% Mounted on
/dev/mapper/wd_blue_label-arti ext4  144G   90G   54G  63% /media/Arti

Partycja ma 144G, wolne 54G, co stanowi 37% -- grubo powyżej deklarowanych w linku 20%. Zobaczmy jak wygląda struktura wolnej przestrzeni na tej partycji:

Kod:

# e2freefrag /dev/mapper/wd_blue_label-arti
Device: /dev/mapper/wd_blue_label-arti
Blocksize: 4096 bytes
Total blocks: 38273024
Free blocks: 14141755 (36.9%)

Min. free extent: 4 KB
Max. free extent: 2064256 KB
Avg. free extent: 25060 KB
Num. free extent: 2257

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :           114           114    0.00%
    8K...   16K-  :           223           496    0.00%
   16K...   32K-  :           119           592    0.00%
   32K...   64K-  :           142          1639    0.01%
   64K...  128K-  :            72          1683    0.01%
  128K...  256K-  :            82          3787    0.03%
  256K...  512K-  :           139         13030    0.09%
  512K... 1024K-  :           138         25596    0.18%
    1M...    2M-  :           328        136317    0.96%
    2M...    4M-  :           283        197920    1.40%
    4M...    8M-  :           343        486042    3.44%
    8M...   16M-  :            52        141984    1.00%
   16M...   32M-  :            33        195394    1.38%
   32M...   64M-  :            49        538921    3.81%
   64M...  128M-  :            58       1376515    9.73%
  128M...  256M-  :            38       1731445   12.24%
  256M...  512M-  :            21       1779232   12.58%
  512M... 1024M-  :            11       2008935   14.21%
    1G...    2G-  :            12       5502113   38.91%

Wgrałem tam kawałek filmu:

Kod:

#  ls -alh  "/media/Arti/film.mkv"
-rwxr----- 1 morfik morfik 1.7G 2021-12-02 14:47:59 '/media/Arti/film.mkv'*

Jak się wgrał? W jednej części? Zobaczmy:

Kod:

#  filefrag -ve "/media/Arti/film.mkv"
Filesystem type is: ef53
File size of /media/Arti/film.mkv is 1756818561 (428911 blocks of 4096 bytes)
ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:   19589120..  19621887:  32768:
   1:    32768..   71679:   19621888..  19660799:  38912:
   2:    71680..   73727:   19718144..  19720191:   2048:   19660800:
   3:    73728..   75775:   19777536..  19779583:   2048:   19720192:
   4:    75776..   77823:   19843072..  19845119:   2048:   19779584:
   5:    77824..   81919:   17045504..  17049599:   4096:   19845120:
   6:    81920..   96255:   17086464..  17100799:  14336:   17049600:
   7:    96256..  129023:   17104896..  17137663:  32768:   17100800:
   8:   129024..  262143:   17139712..  17272831: 133120:   17137664:
   9:   262144..  286719:   17276928..  17301503:  24576:   17272832:
  10:   286720..  288767:   17350656..  17352703:   2048:   17301504:
  11:   288768..  292863:   17358848..  17362943:   4096:   17352704:
  12:   292864..  309247:   17334272..  17350655:  16384:   17362944:
  13:   309248..  335871:   17405952..  17432575:  26624:   17350656:
  14:   335872..  346111:   17446912..  17457151:  10240:   17432576:
  15:   346112..  380927:   17588224..  17623039:  34816:   17457152:
  16:   380928..  385023:   17625088..  17629183:   4096:   17623040:
  17:   385024..  423935:   17674240..  17713151:  38912:   17629184:
  18:   423936..  425983:   17715200..  17717247:   2048:   17713152:
  19:   425984..  428031:   17719296..  17721343:   2048:   17717248:
  20:   428032..  428910:   17713152..  17714030:    879:   17721344: last,eof
/media/Arti/film.mkv: 20 extents found

A miało być tak pięknie, przecie Linux has been built to prevent fragmentation -- RLY? Ktoś może powiedzieć, Ok tylko 20 kawałków na pliku 1,7G ale co się będzie dziać jeśli zaczniemy wgrywać i usuwać dane z takiej partycji bez defragmentacji? No stanie się to o czym w tych durnych poradnikach nie piszą, tj. będziemy mieć do czynienia z coraz większą fragmentacją wolnej przestrzeni i coraz trudniej będzie nam wgrać plik bez fragmentowania go i tak ostatecznie będziemy mieć niesamowity syf, o którym można np. poczytać tutaj. (przeczytaj cały wątek, może i o ext3 ale na ext4 jest bardzo podobnie).

No i jeszcze na zakończenie spróbujmy zdefragmentować ten plik z filmem wyżej:

Kod:

#  e4defrag -v /media/Arti/film.mkv
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 20 -> 15 [ OK ]
Success:                       [1/1]

No trochę lepiej, to drugie przejście:

Kod:

#  e4defrag -v /media/Arti/film.mkv
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 15 -> 12 [ OK ]
Success:                       [1/1]

No proszę, jeszcze 3 kawałki. Choć kolejne 10 prób nie chciał podjąć defragmentacji, dlatego trochę inaczej to zrobimy:

Kod:

# for in in {1..1000}; do e4defrag -v /media/Arti/film.mkv  ;done

e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 12 -> 11 [ OK ]
Success:                       [1/1]
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 11 [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 11 -> 1  [ OK ]
Success:                       [1/1]
e4defrag 1.47.2 (1-Jan-2025)
ext4 defragmentation for /media/Arti/film.mkv
[1/1]/media/Arti/film.mkv:      100%  extents: 1 -> 1   [ OK ]
....

I jeszcze:

Kod:

#  filefrag -ve /media/Arti/film.mkv
Filesystem type is: ef53
File size of /media/Arti/film.mkv is 1756818561 (428911 blocks of 4096 bytes)
ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  428910:   33591296..  34020206: 428911:             last,eof
/media/Arti/film.mkv: 1 extent found

No i proszę -- pełen sukces, mamy plik w jednym kawałku ... hura!!! trybuny szaleją.  Ciekawe czemu od razu nie zrobił z tego jednego kawałka tylko tyle przebiegów potrzebował?

Także trochę to bardziej skomplikowane z tą fragmentacją i defragmentacją plików. Jedno jest pewne, danych się w ten sposób nie traci. Może ten przykład wyżej to trochę taki paranoiczny ale tak z raz na miecha partycje na moich dyskach HDD dostają 10 przebiegami, co znacząco obniża mi stopień fragmentacji plików.

[magnus]

0

Według tego co napisałeś:
Całe społeczeństwo Linuxa jest w błędzie, jednak powinniśmy wykonywać defragmentację dysku.
Każdy kto twierdzi inaczej "wykazuje się niesamowitym brakiem wiedzy".
Każdy "durny" poradnik który twierdzi inaczej to "farmazony" i "można go sobie wsadzić nie powiesz gdzie, i upchnąć jeszcze głębiej".
W walce o "prawdę" jesteś jak Don Kichot walczący z wiatrakami (z tym się zgodzę  )

Test który wykonałeś udowadnia że zachodzi fragmentacja dysku (z tym faktem nikt nie dyskutuje), wątpliwe jest jednak czy defragmentacja którą przeprowadzasz daje jakiekolwiek wymierne korzyści, dodatkowo biorąc pod uwagę że większość z nas używa napędów półprzewodnikowych (SSD).

[morfik]

0

No tak samo jak już to wielokrotnie próbowano odkłamywać rzeczywistość, że linux nie jest bardziej bezpieczny niż windows. Jak człowiek chce wierzyć w coś, co nie ma żadnego odzwierciedlenia w rzeczywistości, to nikt mu tego nie zabroni, zwłaszcza ja, bo ja mam lepsze rzeczy w życiu do roboty.

Ja nie twierdze, że ktokolwiek ma robić cokolwiek na swoim systemie. Napisałeś, że defragmetnacja uszkadza pliki -- to jest wierutna bzdura! Sorry ale tak to nie działa, a jeśli ktoś twierdzi inaczej, to tak, jest idiotą.

Ja nie mam nic do poradników, które chociaż w jakimś stopniu uźródlają swoje twierdzenia, a w tym linku co podałeś nie ma żadnych źródeł czy argumentów wyjaśniających zawarte w nim twierdzenia. Merytoryczność takiego artykułu jest żadna.

Masz czarno na białym przykład wyżej -- odpowiedz mi na pytanie, czemu ten plik nie został wgrany w jednym kawałku? Czemu został wgrany w 20 kawałkach, w sytuacji gdzie bez problemu można było go wgrać w jednym kawałku? Dlaczego linux (i jego system plików ext4), który ma być rzekomo zaprojektowany by nie potrzeba było defragmentować plików, nie potrafi wgrać pliku w jednym kawałku w sytuacji gdy powinien? Mnie to pytanie od ponad dekady zastanawia i póki co nie znalazłem na nie żadnej odpowiedzi -- najwyraźniej nikt do końca nie wie jak linux wgrywa pliki na dysk. I wcale by mnie to nie zdziwiło, bo wbrew powszechnej opinii kernel linux'a to nie jest najzajebistsza rzecz na świecie, a zamiast tego jest pełen błędów i nieprzemyślanych do końca rozwiązań, które przekładają się na bardzo dziwne zachowania tego jądra i podejmowane przez niego decyzje. Nawet na logikę, po co systemowi plików ext4 natywne narzędzie do defragmentacji plików, jeśli ten system plików tego nie wymaga? Ten cały e4defrag jest z pakietu e2fsprogs -- a kto rozwojem tych narzędzi się zajmuje? A no m.in. Theodore Ts'o, tj. jeden z deweloperów system plików ext4. Jeśli deweloper systemu plików tworzy narzędzie mające defragmentować ten system plików, to ja jednak wolę mu zaufać, że on wie lepiej co się w tym systemie plików odbywa.

Test który wykonałeś udowadnia że zachodzi fragmentacja dysku (z tym faktem nikt nie dyskutuje), wątpliwe jest jednak czy defragmentacja którą przeprowadzasz daje jakiekolwiek wymierne korzyści, dodatkowo biorąc pod uwagę że większość z nas używa napędów półprzewodnikowych (SSD).

To dwie rzeczy do przemyślenia:

1. Jak masz dysk magnetyczny i plik w xxx kawałkach, to który odczyt pliku będzie szybszy: a) jeśli głowica ma się raz wypozycjonować i odczytać cały plik, czy jak głowica ma się wypozycjonować xxx razy by odczytać ten sam plik?
2: No sporo osób używa dysków SSD, nawet ja. Powiem więcej, ja nie przeprowadzam defragmentacji na tym rodzaju nośników. I teraz jest inne pytanie czy wydajność operacji na plikach cierpi z powodu ich fragmentacji na dyskach SSD? Odpowiedź jest twierdząca -- znów, wbrew powszechnej opinii. Zatem czemu nie wykonuje defragmentacji na dyskach SSD? Bo muszę dokonać wyboru -- żywotność dysku versus jego wydajność. Gdyby dyski SSD nie cierpiały za sprawą zerowania, to i te nośniki bym defragmentował a tak, to jakoś tę utratę wydajności (mniejszą, większa) przeżyję, w przeciwieństwie do utraty zgromadzonych na takim nośniku danych.

I naprawdę przeczytaj to -- dla zachęty film.avi: 24145 extents found, perfection would be 1 extent

[dedito]

0

Ja nie mam nic do poradników, które chociaż w jakimś stopniu uźródlają swoje twierdzenia, a w tym linku co podałeś nie ma żadnych źródeł czy argumentów wyjaśniających zawarte w nim twierdzenia. Merytoryczność takiego artykułu jest żadna.

No tu autor poradnika ELTP dał link do szerszych wyjaśnień.
https://drive.google.com/file/d/1rIOv22_...W2Ogw/view

Magnus miał na myśli, używanie jakiś "szemranych" programów do defragmentacji, które mogą uszkodzić system i ciężko się tu nie zgodzić. Tak to przynajmniej ja odczytuję.

Myślę, że kwestia fragmentacji jest dosyć złożona i zależy m.in. od konstrukcji dysku, że zacytuję choćby ten kawałek z powyższego linku:

It is also worth knowing that even when an OS says a drive is completely defragmented, due to
the nature of hard drive geometry, fragmentation may still be present: A typical hard drive
actually has multiple disks, AKA platters, inside it.

Inna sprawa, to czy w ogóle warto sobie zawracać głowę fragmentacją w dobie dysków SSD, bo przecież to inna konstrukcja, inny sposób dostępu do danych, czy to w ogóle ma jakieś praktyczne znaczenie, jak to wpływa na opóźnienie w dostępie do danych ...

[morfik]

0

No tak, to jest oczywiste, że jak upychasz jeden plik za drugim i kasujesz potem pliki i wgrywasz coś, co nie mieści się w przestrzeniach pomiędzy, to będzie się fragmentować. Problem nie w takim podejściu ale w podejściu, że jak będziemy wgrywać pliki w "porządku nieciągłycm", to wpłynie to na mniejsza fragmentację -- rzeczywistość zdaje się temu przeczyć, może nie od razu. Wszystko zależy od tego ile danych i jakich danych (wielkość plików) będziemy pchać na dysk i do tego jeszcze w jakim czasie to będziemy robić. No i też oczywiście ile wątków jednocześnie będzie próbować zapisywać dany system plików. Ostatecznie bez defragmentacji i tak skończymy ze 100% fragmetnacją -- po prostu nie ma innej opcji. To tak jak z rozwojem bakterii w kiblu -- od czasu do czasu trzeba je potraktować domestosem,

O szemranych programach się nie wypowiadam -- w tamtym poradniku jak byk stoi Dlatego nie stosuje się defragmentacji, tym bardziej że może to doprowadzić do utraty plików. -- i to jest jak najbardziej bzdura i to powinno zostać zmienione, by nie wprowadzać małotechnicznych ludzi w błąd. Dlatego napisałem swój komentarz.

Co do budowy dysku -- tak, mają wiele talerzy. Mają też wiele głowic, choć na jednym ramieniu. Niemnie jednak, przecitny dysk nie ma więcej niż kilka talerzy. Zatem ten czynnik, jako fragmentujący można zupełnie pominąć.

Inna sprawa, to czy w ogóle warto sobie zawracać głowę fragmentacją w dobie dysków SSD, bo przecież to inna konstrukcja, inny sposób dostępu do danych, czy to w ogóle ma jakieś praktyczne znaczenie, jak to wpływa na opóźnienie w dostępie do danych ...

Kiedyś czytałem artykuł, że fragmentacja (nie jakaś szczątkowa) wpływa i to dość znacznie na wydajność dysków SSD. Jak będę miał chwilę czasu to postaram się poszukać i wrzucić.

[mati75]

0

Masz czarno na białym przykład wyżej -- odpowiedz mi na pytanie, czemu ten plik nie został wgrany w jednym kawałku? Czemu został wgrany w 20 kawałkach, w sytuacji gdzie bez problemu można było go wgrać w jednym kawałku? Dlaczego linux (i jego system plików ext4), który ma być rzekomo zaprojektowany by nie potrzeba było defragmentować plików, nie potrafi wgrać pliku w jednym kawałku w sytuacji gdy powinien? Mnie to pytanie od ponad dekady zastanawia i póki co nie znalazłem na nie żadnej odpowiedzi -- najwyraźniej nikt do końca nie wie jak linux wgrywa pliki na dysk. I wcale by mnie to nie zdziwiło, bo wbrew powszechnej opinii kernel linux'a to nie jest najzajebistsza rzecz na świecie, a zamiast tego jest pełen błędów i nieprzemyślanych do końca rozwiązań, które przekładają się na bardzo dziwne zachowania tego jądra i podejmowane przez niego decyzje. Nawet na logikę, po co systemowi plików ext4 natywne narzędzie do defragmentacji plików, jeśli ten system plików tego nie wymaga? Ten cały e4defrag jest z pakietu e2fsprogs -- a kto rozwojem tych narzędzi się zajmuje? A no m.in. Theodore Ts'o, tj. jeden z deweloperów system plików ext4. Jeśli deweloper systemu plików tworzy narzędzie mające defragmentować ten system plików, to ja jednak wolę mu zaufać, że on wie lepiej co się w tym systemie plików odbywa.

Mnie to też zastanawia. Jak wchodziłem te 20 lat temu w świat linux to jego przewagą było, że nie trzeba defragmentować dysków. Tyle lat minęło i nagle się okazuje, że w przypadku dysków ssd ta defragmentacja to jednak by się przydała, bo głowic już nie ma a równomierne zużycie kości jest lepsze.

Kolejna rzecz, zarządzałem klastrami danych o rozmiarach który zwykły użytkownik komputera z linux może zapomnieć i nigdy nie widzieć. Nigdy nie było tam ext4, tylko zfs, cephfs, glusterfs lub btrfs. Z powodu tak prostej rzeczy jak uszkadzanie się ext* samemu z siebie jest on pomijany. Tak samo z jakiegoś powodu przyjęło się żeby np. partycje boot robić ext2 a nie nowszych.

Co prawda jest to nadal lepiej jak dosowe fat i windowsowy ntfs, ale nadal nie jest super idealnie, bo okazuje się BSD i solaris mają lepsze rozwiązania, a 90% linuksiarzy o nich nie słyszała.