🚀 go-pugleaf

On 15.12.2024 18:50, szopen wrote:
> Narzędzia wizualnie przedstawiające zajętość dysku jak Filelight pokazują, że /home ma 60,3GB, czyli mniej więcej ok.
> Ale np. menager plików Kubuntu czyli Dolphin też pokazuje wolne tylko 21,9GB.
> 
> O co chodzi? Jak to dokładnie zdiagnozować?

I jeszcze:

❯ du -hx -d 1 /home

60G     /home/szopen
16K     /home/lost+found
60G     /home


-- 
szopen

On 2024-12-15 at 19:33 szopen wrote:
>> Narzędzia wizualnie przedstawiające zajętość dysku jak Filelight pokazują,
>> że /home ma 60,3GB, czyli mniej więcej ok.
>> Ale np. menager plików Kubuntu czyli Dolphin też pokazuje wolne tylko 21,9GB.
>>
>> O co chodzi? Jak to dokładnie zdiagnozować?

Jedne narzędzia pokazują ilość zajętego/wolnego miejsca w filesystemie,
a inne sumę rozmiarów dostępnych plików i katalogów.  Różnica najczęściej
wynika z powodu skasowanych, ale jeszcze nie zamkniętych przez procesy
plików -- programy liczące sumę rozmiarów plików już ich nie widzą, ale
miejsce w filesystemach te pliki wciąż jeszcze zajmują.  Możesz sobie
przeanalizować wynik polecenia:

file /proc/[0-9]*/fd/* | grep /home | grep deleted

które pokaże, które procesy trzymają otwarte, ale już skasowane pliki
w /home -- może coś ci to podpowie.  Myślę, że pomóc powinno wylogowanie się
z KDE i zakończenie wszystkich procesów usera szopen, albo, chyba szybciej,
zwyczajny reboot.

Innym powodem raportowania nieprawidłowej zajętości filesystemu może być
jego uszkodzenie -- rzadko, ale się zdarza.  Popatrz, co na niepodmontowanym
/dev/nvme2n1p3 pokaże polecenie:

fsck -fnv /dev/nvme2n1p3

On 16.12.2024 02:15, marrgol wrote:

>>> O co chodzi? Jak to dokładnie zdiagnozować?
> 
> Jedne narzędzia pokazują ilość zajętego/wolnego miejsca w filesystemie,
> a inne sumę rozmiarów dostępnych plików i katalogów.  Różnica najczęściej
> wynika z powodu skasowanych, ale jeszcze nie zamkniętych przez procesy
> plików -- programy liczące sumę rozmiarów plików już ich nie widzą, ale

Wiesz, chyba nie wybrzmiało to zbyt wyraźnie, a Ty nie musiałeś tego wyczytać między wierszami.
Problem polega na tym, że plików na /home jest około 60GB, a narzędzia od partycjonowania pokazują zajętość na poziomie 
690GB.

60GB vs 690GB!

Także manager plików Kubuntu durnieje.

> miejsce w filesystemach te pliki wciąż jeszcze zajmują.  Możesz sobie
> przeanalizować wynik polecenia:
> 
> file /proc/[0-9]*/fd/* | grep /home | grep deleted

Jakiś jeden plik był. Nieistotny.

> które pokaże, które procesy trzymają otwarte, ale już skasowane pliki
> w /home -- może coś ci to podpowie.  Myślę, że pomóc powinno wylogowanie się
> z KDE i zakończenie wszystkich procesów usera szopen, albo, chyba szybciej,
> zwyczajny reboot.

Rebooty nic nie zmieniają.

> Innym powodem raportowania nieprawidłowej zajętości filesystemu może być
> jego uszkodzenie -- rzadko, ale się zdarza.  Popatrz, co na niepodmontowanym
> /dev/nvme2n1p3 pokaże polecenie:
> 
> fsck -fnv /dev/nvme2n1p3

Odpaliłem kompa z pena z ubuntu live.

ubuntu-mate@ubuntu-mate:~$ sudo fsck.ext4 -fv /dev/nvme2n1p3
e2fsck 1.47.1 (20-May-2024)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

       499731 inodes used (1.01%, out of 49479680)
        10968 non-contiguous files (2.2%)
          387 non-contiguous directories (0.1%)
              # of inodes with ind/dind/tind blocks: 0/0/0
              Extent depth histogram: 491367/931/2
    182247158 blocks used (92.10%, out of 197888512)
            0 bad blocks
           75 large files

       452053 regular files
        39589 directories
            0 character device files
            0 block device files
            1 fifo
         6874 links
         8078 symbolic links (7421 fast symbolic links)
            1 socket
------------
       506596 files

Nie wiem jak to interpretować, ale te 92% brzmi groźnie.


-- 
szopen

szopen <szop@en.szop> writes:

> Zauważyłem w managerze partycji KDE, że moja partycja /home ma zajętę 97% z 754GB, co mnie mocno zaskoczyło.
> GParted pokazuje prawie to samo, trochę mniej, ale może inaczej GB liczy (czyli GiB lub odwrotnie).
>
> To jest niemożliwe, więc odpaliłem:
>
> ❯ df -Th
> [...]
> /dev/nvme2n1p3                     ext4      742G  683G   22G  97% /home

Pomyślalem o jakimś 'sparse' pliku, ale  z tego co widzę, df powinien
pokazać dobrze, więc ... nie wiem.

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
I get my exercise acting as pallbearer to my friends who exercise.
		-- Chauncey Depew

On 15.12.2024 18:50, szopen wrote:
> 
> O co chodzi? Jak to dokładnie zdiagnozować?

Jeszcze dorzuce screenshota, to czasem pomaga.
Na obrazku widać na górze manager partycji, a na dole aplikacje obliczającą i prezentującą wizualnie zajętość partycji:

https://i.imgur.com/9FGh3cx.png

-- 
szopen

On 16.12.2024 07:54, Kamil Jońca wrote:

 >> ❯ df -Th
 >> [...]
 >> /dev/nvme2n1p3                     ext4      742G  683G   22G  97% /home
 >
 > Pomyślalem o jakimś 'sparse' pliku, ale  z tego co widzę, df powinien
 > pokazać dobrze, więc ... nie wiem.
 >
 > KJ


Rozwiń proszę tę myśl.
Tutaj df pokazał, że jest zajęte 683GB, czy to wyklucza plik sparse? I jak ich szukać?

-- 
szopen

szopen <szop@en.szop> writes:

> On 16.12.2024 07:54, Kamil Jońca wrote:
>
>>> ❯ df -Th
>>> [...]
>>> /dev/nvme2n1p3                     ext4      742G  683G   22G  97% /home
>>
>> Pomyślalem o jakimś 'sparse' pliku, ale  z tego co widzę, df powinien
>> pokazać dobrze, więc ... nie wiem.
>>
>> KJ
>
>
> Rozwiń proszę tę myśl.
> Tutaj df pokazał, że jest zajęte 683GB, czy to wyklucza plik sparse? I jak ich szukać?

o ile wiem (zweryfikuj!) df bierze pod uwagę faktycznie zajęte bloki
czyli w przypadku
--8<---------------cut here---------------start------------->8---
if=/dev/zero of=qqrq bs=1M count=1 seek=8191
--8<---------------cut here---------------end--------------->8---
powinien uwzględnić 1M  a nie 8G (zrobiłem eksperyment który wydaje się
to potwierdzać)

--8<---------------cut here---------------start------------->8---
kjonca@alfa:~%df -h /home/kjonca                                       
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/alfa-home  1,8T  1,6T  123G  93% /home
kjonca@alfa:~%dd if=/dev/zero of=qqrq bs=1M count=1 seek=100000
1+0 records in
1+0 records out
1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,000906781 s, 1,2 GB/s
kjonca@alfa:~%df -h /home/kjonca                               
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/alfa-home  1,8T  1,6T  123G  93% /home
--8<---------------cut here---------------end--------------->8---
Więc to raczej nie pliki 'sparse'
Stąd mi pomysły się skończyły.


KJ


-- 
http://wolnelektury.pl/wesprzyj/teraz/
I wish you humans would leave me alone.

On 16.12.2024 09:13, Kamil Jońca wrote:

> Więc to raczej nie pliki 'sparse'
> Stąd mi pomysły się skończyły.

Dzięki za chęci. Obu Panom zresztą.

A teraz co było...
Wróciłem do systemu live z pena i postanowiłem tam pogrzebać.
No i nigdy byście na to nie wpadli, ja też nie :-)

Ostatnio dołożyłem nowy dysk i postanowiłem nieco zreorganizować swoje dane, głównie wirtualki, których mam sporo.
Nowy dysk został podpięty, ale chyba coś poszło nie tak z montowaniem na początku, bo się okazało, że w katalogu:

~/storage/kingston

gdzie mam podmontowany ten nowy dysk 2TB, były dane! Czyli katalog nie był pusty, skopiowałem tam część obrazów 
wirtualek (myśląc chyba, że już kpiouje na nowy dysk), a potem na to zamontowałem nowy dysk z innymi wirtualkami, który 
ukrył te pliki pod spodem!

Jakiś durny błąd i dane zniknęły, albo raczej się ukryły. Bardzo ciekawa rzecz, można by to w sumie sprytnie wykorzystać.
Ale wpaść na to, gdyby tam było mniej danych, nie ma szans.

Ufff... można się rozejść :-)

-- 
szopen

On 2024-12-16 at 07:47 szopen wrote:
>>>> O co chodzi? Jak to dokładnie zdiagnozować?
>>
>> Jedne narzędzia pokazują ilość zajętego/wolnego miejsca w filesystemie,
>> a inne sumę rozmiarów dostępnych plików i katalogów.  Różnica najczęściej
>> wynika z powodu skasowanych, ale jeszcze nie zamkniętych przez procesy
>> plików -- programy liczące sumę rozmiarów plików już ich nie widzą, ale
> 
> Wiesz, chyba nie wybrzmiało to zbyt wyraźnie, a Ty nie musiałeś tego
> wyczytać między wierszami.
> Problem polega na tym, że plików na /home jest około 60GB, a narzędzia od
> partycjonowania pokazują zajętość na poziomie 690GB.
> 
> 60GB vs 690GB!

Zauważyłem.  Różnica owszem duża, co nie znaczy, że niemożliwa -- zapytałeś
jak to diagnozować, to napisałem jaka jest najczęstsza przyczyna i jak to
sprawdzić, a nie że tak musi być u Ciebie.

> Odpaliłem kompa z pena z ubuntu live.
> 
> ubuntu-mate@ubuntu-mate:~$ sudo fsck.ext4 -fv /dev/nvme2n1p3
> e2fsck 1.47.1 (20-May-2024)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> 
>       499731 inodes used (1.01%, out of 49479680)
>        10968 non-contiguous files (2.2%)
>          387 non-contiguous directories (0.1%)
>              # of inodes with ind/dind/tind blocks: 0/0/0
>              Extent depth histogram: 491367/931/2
>    182247158 blocks used (92.10%, out of 197888512)
>            0 bad blocks
>           75 large files
> 
>       452053 regular files
>        39589 directories
>            0 character device files
>            0 block device files
>            1 fifo
>         6874 links
>         8078 symbolic links (7421 fast symbolic links)
>            1 socket
> ------------
>       506596 files
> 
> Nie wiem jak to interpretować, ale te 92% brzmi groźnie.

Gdybyś wiedział, to w kontekście „problemu” z zajętością filesystemu
to nie te 92% rzuciłoby Ci się w oczy, tylko „75 large files”, czyli
75 plików o wielkości ok. 2GB lub większych, co daje co najmniej 150GB,
a więc już sporo więcej niż oczekiwane 60.  Wtedy od razu po wykonaniu
fsck zamontowałbyś ten filesystem, odszukał te duże pliki i w ten sposób
szybciej i łatwiej doszedłbyś do tego, do czego w końcu doszedłeś. ;)

On 16.12.2024 21:39, marrgol wrote:
> On 2024-12-16 at 07:47 szopen wrote:
>>>>> O co chodzi? Jak to dokładnie zdiagnozować?
>>>
>>> Jedne narzędzia pokazują ilość zajętego/wolnego miejsca w filesystemie,
>>> a inne sumę rozmiarów dostępnych plików i katalogów.  Różnica najczęściej
>>> wynika z powodu skasowanych, ale jeszcze nie zamkniętych przez procesy
>>> plików -- programy liczące sumę rozmiarów plików już ich nie widzą, ale
>>
>> Wiesz, chyba nie wybrzmiało to zbyt wyraźnie, a Ty nie musiałeś tego
>> wyczytać między wierszami.
>> Problem polega na tym, że plików na /home jest około 60GB, a narzędzia od
>> partycjonowania pokazują zajętość na poziomie 690GB.
>>
>> 60GB vs 690GB!
> 
> Zauważyłem.  Różnica owszem duża, co nie znaczy, że niemożliwa -- zapytałeś
> jak to diagnozować, to napisałem jaka jest najczęstsza przyczyna i jak to
> sprawdzić, a nie że tak musi być u Ciebie.

Oczywiście, nie krytykuję przecież. Choć nawiasem, gdybym skasował 600GB to bym chyba miał jakieś odczucie w tyle głowy, 
że to może mieć związek ;-)

>> Odpaliłem kompa z pena z ubuntu live.
>>
>> ubuntu-mate@ubuntu-mate:~$ sudo fsck.ext4 -fv /dev/nvme2n1p3
>> e2fsck 1.47.1 (20-May-2024)
>> Pass 1: Checking inodes, blocks, and sizes
>> Pass 2: Checking directory structure
>> Pass 3: Checking directory connectivity
>> Pass 4: Checking reference counts
>> Pass 5: Checking group summary information
>>
>>        499731 inodes used (1.01%, out of 49479680)
>>         10968 non-contiguous files (2.2%)
>>           387 non-contiguous directories (0.1%)
>>               # of inodes with ind/dind/tind blocks: 0/0/0
>>               Extent depth histogram: 491367/931/2
>>     182247158 blocks used (92.10%, out of 197888512)
>>             0 bad blocks
>>            75 large files
>>
>>        452053 regular files
>>         39589 directories
>>             0 character device files
>>             0 block device files
>>             1 fifo
>>          6874 links
>>          8078 symbolic links (7421 fast symbolic links)
>>             1 socket
>> ------------
>>        506596 files
>>
>> Nie wiem jak to interpretować, ale te 92% brzmi groźnie.
> 
> Gdybyś wiedział, to w kontekście „problemu” z zajętością filesystemu
> to nie te 92% rzuciłoby Ci się w oczy, tylko „75 large files”, czyli
> 75 plików o wielkości ok. 2GB lub większych, co daje co najmniej 150GB,

Tu warunkiem jest wiedza, że "large" znaczy >2GB :-)

> a więc już sporo więcej niż oczekiwane 60.  Wtedy od razu po wykonaniu
> fsck zamontowałbyś ten filesystem, odszukał te duże pliki i w ten sposób
> szybciej i łatwiej doszedłbyś do tego, do czego w końcu doszedłeś. ;)

Ale ogólnie racja, postaram się utrwalić tę informację w neuronach :-)

Thx jeszcze raz

-- 
szopen