Polskie Forum Użytkowników Debiana

Cześć

Mam partycję ext4 524 GB (dysk 532G) z czego zajęte jest 489 GB. Z moich obliczeń wynika, że wolne powinno być ~35 GB. Tak też raportuje Gparted. Nie mniej df wskazuje, że wolne miejsce to 13 GB i tyle faktycznie chyba pozostało do dyspozycji. Czy ktoś z grupowiczów, może mi rzucić trop skąd wynika ta rozbieżność.

/dev/sdc1 524G 489G 13G 98% /var/vmail


Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 1115684863 1115682816 532G 83 Linux

Pokaż pełny wynik polecenia i jako root

pomocne będzie polecenie du
du - szacuje użycie miejsca na dysku


W razie potrzeby dodatkowy inforamacji o du wpisz w konsole lub
A czy wiesz że 1GB = 1024MB
a każdy myśli że 1 GB to 1000MB
i potem tacy co niektorzy się budzą i szukaja tych GB na dysku bo gdzieś zginęło. Poza tym dyski nigdy nie mają tyle terenu użytecznego co mówią producenci na etykietach dysku.

Bo producenci podają rozmiar dysku w systemie dziesiętnym.

@dedito, takie informacje już przytoczyłem na samym poczatku wątku.
Tutaj pojawia się niewielka rozbieżność rzędu 70 MB, która w kontekście mojego pytania nie specjalnie mnie interesuje (choć faktycznie może mieć to jakiś związek z zagadnieniem). W zasadzie wartości df i du pokrywają się.

Uwaga na temat problematyki "zaginionego" miejsca w wyniku przeliczania jednostek jest mi znana. Może błędnie, ale zakładam że różnice rozmiaru podanych systemem dziesiętnym, a binarnym wychodzą: dysk 532G v rozmiar partycji 524 GB (wartość na etykiecie v system). Swoją drogą tutaj jest różnica tylko na poziomie 8 GB. Kojarzę z partycji widnowsowych, że z dysku 500GB odkrojone zostaje jakieś 30 GB, co stanowi większa rozbieżność. Jak widać, w tym miejscu również można się doszukiwać pewnej nieścisłości i być może któryś z kolegów się do tego odniesie. Dodam, że dysk jest wirtualny. Bez zgłębiania tematu, może błędnie, ale założyłem, że "rozmiar dysku" tak naprawdę stanowi alokację na macierzy, a owe 8 GB to strata na dane niezbędne do jego utrzymania.

Najbardziej mnie nurtuje, dlaczego suma dwóch ostatnich kolumn nie pokrywa się z wartością pierwszej kolumny tj."rozmiar". W tym zestawieniu brakuje mi jeszcze jednej wartości, która reprezentowała by różnicę której pochodzenie nie potrafię zdefiniować.

df podaje trzy wartości: rozm. użyte dost

548957480 512365548 12900184

512365548 (użyte) + 12900184 (dostępne) = 525 265 732 (suma)

Zakładam, że rozmiar partycji (wiem, że nie dysku) = użyte miejsce + wolne miejsce.
Spodziewałem się, że 'rozmiar' będzie równy sumie, arealnie wychodzi co innego:

548957480 (rozmiar) - 525 265 732 (suma) daje rozbieżność ponad 20 GB: 23 691748



Swoją drogą wątek nadaje się do działu "wasze wtopy" bo właśnie zdałem sobie sprawę, że na wszystkich maszynach, przez kilka lat te wartości szacowałem "na oko" skupiając się jedynie na rezerwie wolnego miejsca. Okazuje się, że operując na wartościach rzędu dziesiątek czy setek, ten ogon niezauważenie traci się gdzieś w gąszczu innych spraw.

U mnie dysk SSD 240 GB, przy dwóch partycjach jakie mam na dysku w systemie MBR a wiec 240 - (13+208)=19
kto mi zjadł dysk?
]:>

Może rozbieżność wynika z tego że jest jeszcze coś takiego jak: Zarezerwowane miejsce w systemie plików
https://morfikov.github.io/post/zarezer ... ikow-ext4/

Ps.:
Sektory zapasowe albo chińskie GB

6,5 + 5,7 = 12,2
162 + 36 = 198

Łącznie daje 210,02, a rzekomo powinno być 221 GB
Tu Cię skubneli na kolejne 10,8 GB. I właśnie o te wartość pytałem.

@Saturno, myślę, że masz rację. Zapoznalem się z artykułem, przeliczylem wartości, co prawda z marszu bez użycia kalkulatora ale faktycznie może chodzić o domyślne 5 - 6 ÷ rezerwacji na potrzeby ważnych procesów systemowych.

Wartości te zgadzają mi się z moim przypadkiem, jak i przykładu przedmowy.
Dziękuję za wyjaśnienia.

dedito pisze: ↑21 marca 2020, 11:13 Bo producenci podają rozmiar dysku w systemie dziesiętnym.

Raczej wszyscy tak podaj -- inaczej ciężko by się było połapać ile ten dysk ma tych giga...

Tu przykład:

532 -- dziesiętny
0010 0001 0100 -- binarny
0x214 -- hexalny