EXT4 kradnie miejsce na dysku defragmentacja?

Tutaj można zadać pytanie, jeśli Linuksa widzi się pierwszy raz w życiu ;)
Lisciu
Piegowaty Guziec
Piegowaty Guziec
Posty: 7
Rejestracja: 06 maja 2017, 14:31
Płeć: Mężczyzna
Wersja Ubuntu: 20.04
Środowisko graficzne: GNOME
Architektura: x86_64

EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Lisciu »

Witam wszystkich

System Ubuntu 20.04.6 LTS
dysk SSD 500GB
System plików EXT4

Od dłuższego czasu wyskakuje mi informacja ze mam 16MB wolnego miejsca na dysku ale gdy odpale Gparted pokazuje że jednak jest grubo ponad 7GB wolnego miejsca.
Ktoś mi tłumaczył ze tu chodzi o jakies małe fragmenty które tworzą dysk i które są niedopisywane do końca i to powoduje że niby jest 16MB.
Różnica jest ogromna i problem z 16MB wolnego miejsca powoduje że nie za bardzo mam jak pracować. Już słyszałem że super duper stabilny i taki świetny system plików EXT4 nic nie wymaga że sie sam defragmentuje i ze jeszcze raz jest super stabilny ale jak mi kradnie 7GB to moim zdaniem nie jest taki super a wręcz przereklamowany. bo fragmentacja jest do bani bo niemożliwa a z części dysku wydzielonej dla Ubuntu (bo w drugiej czesci mam Windowsa) wyczerpała się momentalnie i moim zdaniem właśnie przez system plików EXT4.

Czy jest coś co pomoże mi zrobić z tym porządek? (e4defrag)?
Pomożecie mi sprawdzić co i jak?

Z góry dzięki za pomoc
Rgl
Serdeczny Borsuk
Serdeczny Borsuk
Posty: 225
Rejestracja: 08 sty 2006, 08:10
Płeć: Mężczyzna
Wersja Ubuntu: 24.10
Środowisko graficzne: GNOME
Architektura: x86_64
Lokalizacja: Warszawa

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Rgl »

System plików ext4 część wolnego miejsca rezerwuje dla użytkownika root. Domyślnie jest to 5%. Ilość zarezerwowanych bloków możesz sprawdzić poleceniem tune2fs
przykładowo u mnie sprawdzenie partycji /dev/sda2 tworzonej pod Ubuntu:

Kod: Zaznacz cały

user@host:~$ sudo tune2fs -l /dev/sda2
[sudo] hasło użytkownika user: 
tune2fs 1.47.1 (20-May-2024)
Filesystem volume name:   <none>
Last mounted on:          /run/media/user/3f82999d-644a-4a82-99b6-71e30a3bb664
Filesystem UUID:          3f82999d-644a-4a82-99b6-71e30a3bb664
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              17711104
Block count:              70815232
Reserved block count:     3540761
Overhead clusters:        1388787
Free blocks:              9119635
Free inodes:              17067514
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1007
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Nov 28 19:00:17 2021
Last mount time:          Sat Oct 26 11:00:47 2024
Last write time:          Sun Oct 27 11:19:57 2024
Mount count:              656
Maximum mount count:      -1
Last checked:             Sun Nov 28 19:00:17 2021
Check interval:           0 (<none>)
Lifetime writes:          2333 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e78dab44-5e1d-4efc-90c1-91e9b18fe1f0
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0xdd14cf10
Zarezerwowanych mam 3 540 761 bloków co przy rozmiarze bloku 4096 stanowi dosyć dużą ilość miejsca. Przy czym na dyskach które nie są dyskami systemowymi taka rezerwacja nie jest raczej do niczego potrzebna.
Domyślne 5% przy dzisiejszych rozmiarach dysku to też raczej trochę za dużo.
Jaki procent bloków ma być zarezerwowany dla procesów uprzywilejowanych można ustawić parametrem -m dla tune2fs.
Jeżeli to jest dysk tylko na dane możesz wyłaczyć rezerwację przez

Kod: Zaznacz cały

sudo tune2fs -m 0  /dev/tu_nazwa_urządzenia
Jeżeli jednak jest to dysk systemowy pozostawiłnbym jednak trochę zarezerwowanego miejsca aby nie uniemożliwić startu systemu w razie zapełnienia systemu plików.
EDIT
W parametrze -m podajesz procent miejsca jaki ma być zarezerwowany np -m 3 ustawi że zarezerwowane pozostanie 3% miejsca.
Lisciu
Piegowaty Guziec
Piegowaty Guziec
Posty: 7
Rejestracja: 06 maja 2017, 14:31
Płeć: Mężczyzna
Wersja Ubuntu: 20.04
Środowisko graficzne: GNOME
Architektura: x86_64

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Lisciu »

Rgl pisze: 11 lis 2024, 12:38 System plików ext4 część wolnego miejsca rezerwuje dla użytkownika root. Domyślnie jest to 5%. Ilość zarezerwowanych bloków możesz sprawdzić poleceniem tune2fs
przykładowo u mnie sprawdzenie partycji /dev/sda2 tworzonej pod Ubuntu:

Kod: Zaznacz cały

user@host:~$ sudo tune2fs -l /dev/sda2
[sudo] hasło użytkownika user: 
tune2fs 1.47.1 (20-May-2024)
Filesystem volume name:   <none>
Last mounted on:          /run/media/user/3f82999d-644a-4a82-99b6-71e30a3bb664
Filesystem UUID:          3f82999d-644a-4a82-99b6-71e30a3bb664
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              17711104
Block count:              70815232
Reserved block count:     3540761
Overhead clusters:        1388787
Free blocks:              9119635
Free inodes:              17067514
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1007
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Nov 28 19:00:17 2021
Last mount time:          Sat Oct 26 11:00:47 2024
Last write time:          Sun Oct 27 11:19:57 2024
Mount count:              656
Maximum mount count:      -1
Last checked:             Sun Nov 28 19:00:17 2021
Check interval:           0 (<none>)
Lifetime writes:          2333 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e78dab44-5e1d-4efc-90c1-91e9b18fe1f0
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0xdd14cf10
Zarezerwowanych mam 3 540 761 bloków co przy rozmiarze bloku 4096 stanowi dosyć dużą ilość miejsca. Przy czym na dyskach które nie są dyskami systemowymi taka rezerwacja nie jest raczej do niczego potrzebna.
Domyślne 5% przy dzisiejszych rozmiarach dysku to też raczej trochę za dużo.
Jaki procent bloków ma być zarezerwowany dla procesów uprzywilejowanych można ustawić parametrem -m dla tune2fs.
Jeżeli to jest dysk tylko na dane możesz wyłaczyć rezerwację przez

Kod: Zaznacz cały

sudo tune2fs -m 0  /dev/tu_nazwa_urządzenia
Jeżeli jednak jest to dysk systemowy pozostawiłnbym jednak trochę zarezerwowanego miejsca aby nie uniemożliwić startu systemu w razie zapełnienia systemu plików.
EDIT
W parametrze -m podajesz procent miejsca jaki ma być zarezerwowany np -m 3 ustawi że zarezerwowane pozostanie 3% miejsca.
Dzięki za odpowiedź.
Jest to partycja: /home. Na systemowej mam sporo miejsca i tam nie ma problemu bo dałem nawet za dużo zapasu na dane.
U mnie wygląda to tak

Kod: Zaznacz cały

pablo@Komputer:~$ sudo tune2fs -l /dev/sda6
[sudo] hasło użytkownika pablo: 
tune2fs 1.45.5 (07-Jan-2020)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          23f7dea7-aad2-4f81-b1a8-6067e61f7a35
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              9887744
Block count:              39533568
Reserved block count:     1976678
Free blocks:              1982426
Free inodes:              9791954
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Jan 16 15:23:18 2022
Last mount time:          Mon Nov 11 13:14:18 2024
Last write time:          Mon Nov 11 13:14:18 2024
Mount count:              1085
Maximum mount count:      -1
Last checked:             Sun Jan 16 15:23:18 2022
Check interval:           0 (<none>)
Lifetime writes:          423 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      42bdd9a3-d60f-437d-b156-3c61b1aa072d
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x03356886
Pozdrawiam
Awatar użytkownika
jacekalex
Gibki Gibbon
Gibki Gibbon
Posty: 4707
Rejestracja: 17 cze 2007, 02:54
Płeć: Mężczyzna
Wersja Ubuntu: inny OS
Środowisko graficzne: MATE
Architektura: x86_64

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: jacekalex »

Zobacz, z konta root, wynik:

Kod: Zaznacz cały

fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
Wklej tutaj wyjście powyższego polecenia.
Problemy rozwiązujemy na forum nie na PW -> Niech inni na tym skorzystają.
Komputer jest jak klimatyzacja - gdy otworzysz okna, robi się bezużyteczny...
Linux User #499936
Inny OS: Gentoo Linux :)
Lisciu
Piegowaty Guziec
Piegowaty Guziec
Posty: 7
Rejestracja: 06 maja 2017, 14:31
Płeć: Mężczyzna
Wersja Ubuntu: 20.04
Środowisko graficzne: GNOME
Architektura: x86_64

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Lisciu »

jacekalex pisze: 26 lis 2024, 21:46 Zobacz, z konta root, wynik:

Kod: Zaznacz cały

fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
Wklej tutaj wyjście powyższego polecenia.
Cześć. Dzieki za odzew
Kopiuje cale polecenie ale terminal zwraca mi to:
pablo@Komputer:~$ sudo fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
fstrim: nieznana opcja '--listed-in'
'fstrim --help' wyświetli więcej informacji.
pablo@Komputer:~$
Dodam że wczesniej zrobiłem migracje /home na inna partycje i dlatego dziwi mnie to że Ubuntu 20.04 zjadło już 102GB :shock:
Ale program dyski pokazuje mi że mam nadal dostępne 67GB wolnego miejsca :pt36:
Awatar użytkownika
kobrawerde
Gibki Gibbon
Gibki Gibbon
Posty: 2199
Rejestracja: 10 wrz 2006, 16:00
Płeć: Mężczyzna
Wersja Ubuntu: 22.04
Środowisko graficzne: Cinnamon
Architektura: x86_64
Kontakt:

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: kobrawerde »

Dodam że wczesniej zrobiłem migracje /home na inna partycje i dlatego dziwi mnie to że Ubuntu 20.04 zjadło już 102GB :shock:
Może coś namieszałeś w systemie i dlatego masz takie ..."kwiatki" ? no bo na zdrowy rozum jeśli by ten system plików ext4 był taki do bani to więcej było by takich przypadków zjadania GB -ów
Serwer: LinuxMint/Ubuntu 22.04/HWE kernel/Vsftpd/Kodi/Jellyfin/iptv-dvbt2/etc.
CPU: Intel N100 / RAM: 32GB DDR5
Storage: Lexar NM620 2TB M.2 - (x2)
Mobo: MiniPC (Topton X6C )
Laptop: Lenovo Legion 5 Pro 16ITH6H /Ram32GB/ssd500GB/ssd1TB
Lisciu
Piegowaty Guziec
Piegowaty Guziec
Posty: 7
Rejestracja: 06 maja 2017, 14:31
Płeć: Mężczyzna
Wersja Ubuntu: 20.04
Środowisko graficzne: GNOME
Architektura: x86_64

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Lisciu »

kobrawerde pisze: 28 lis 2024, 18:56
Dodam że wczesniej zrobiłem migracje /home na inna partycje i dlatego dziwi mnie to że Ubuntu 20.04 zjadło już 102GB :shock:
Może coś namieszałeś w systemie i dlatego masz takie ..."kwiatki" ? no bo na zdrowy rozum jeśli by ten system plików ext4 był taki do bani to więcej było by takich przypadków zjadania GB -ów


Możliwe że coś popsułem. Mam takie wrażenie jakby pliki zapisywane były w dwóch lokalizacjach i w ten sposób zapełniło mi partycje systemową.
Migracje wykonałem w ten sposób:

Źródło: viewtopic.php?t=179158
1. Utwórz folder tymczasowy Home.

zobacz na której partycji będzie "home" i jaki UUID ma ta partycja:
sudo blkid

edytuj plik fstab:
sudo gedit /etc/fstab

dodaj na końcu pliku:
UUID=xxx-xxxxx-xxxxx /media/home ext4 defaults 0 2

Następnie utwórz punkt montowania:
sudo mkdir /media/home

i zaktualizuj fstab
sudo mount -a

Teraz powinieneś zobaczyć folder /home w katalogu mediów.

2. Skopiuj pliki z bieżącego katalogu domowego do nowego katalogu domowego.

Skopiuj wszystkie pliki z aktualnego katalogu domowego do nowego folderu głównego.
Możesz po prostu zrobić: "Zaznacz wszystko", "Kopiuj" i "Wklej", aby przenieść wszystkie pliki do nowego folderu głównego.
Może się jednak okazać, że brakuje w nim ukrytych plików i niektóre prawa do plików mogą być nie zachowane.
Pewniejszy sposób będzie za pomocą rsync.
sudo rsync -aXS /home/. /media/home/.

3. Przeniesienie aktualnego katalogu Home.
Kiedy już stworzyliśmy nowy katalog domowy, musimy usunąć istniejący katalog domowy, aby zrobić miejsce dla nowego folderu home.
Aby to zrobić, wpisz następujące polecenia w terminalu:
cd /
sudo mv /home /home_backup
sudo mkdir /home
Powyższe polecenie przeniesie istniejący folder macierzysty do /home_backup i utworzy pusty katalog domowy do zamontowania.

4. Zamontuj nowy katalog domowy
Ostatnim krokiem do zakończenia migracji jest zamontowanie nowego folderu domowego jako "/home".
Aby to zrobić, musimy zrewidować plik fstab ponownie.
sudo gedit /etc/fstab

Wszystko co musisz zrobić, to zmienić "/media/home" na "/home". Zapisz i zamknij plik.
Przeładuj plik fstab.
sudo mount -a

Usuń folder /home_backup
sudo rm -rf /home_backup
Planuje przejście na ubuntu 24.04 i stwierdziłem ze zamiast robić migrację /home po prostu zrobię jedną wielką partycje. Coś za bardzo problematyczne się to zrobiło a przecież z opisu wyżej nie jest to nazbyt skomplikowane, Tym bardziej że jest to dla mnie w miare zrozumiałe no i na zasadzie kopiuj wklej :teeh:

Da się coś z tym zrobić albo chociaż zlokalizować gdzie leży problem (może gdzie coś poszło nie tak podczas migracji) dla potomnych?

Z góry dzięki za pomoc
Awatar użytkownika
kobrawerde
Gibki Gibbon
Gibki Gibbon
Posty: 2199
Rejestracja: 10 wrz 2006, 16:00
Płeć: Mężczyzna
Wersja Ubuntu: 22.04
Środowisko graficzne: Cinnamon
Architektura: x86_64
Kontakt:

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: kobrawerde »

Sam robiłem według tego tuto-riala więc na pewno nie jest to winowajca twoich problemów :-) ( no chyba że podczas robienia według tego zrobiłeś jakiś błąd ale tego teraz nie zweryfikujemy ) ... ewidentnie teraz system zgłupiał i podaje niepoprawne dane. Chyba coś jest pomieszane z montowanymi partycjami ?
Możesz porównać co pokazują pewne komendy z pod terminala w systemie:

Kod: Zaznacz cały

cd /
sudo du -sh * | sort -h

Kod: Zaznacz cały

sudo fdisk -l
partycja systemowa wielkość

Kod: Zaznacz cały

sudo du -xsh / | sort -h
zweryfikować wpisy w pliku fstab
Serwer: LinuxMint/Ubuntu 22.04/HWE kernel/Vsftpd/Kodi/Jellyfin/iptv-dvbt2/etc.
CPU: Intel N100 / RAM: 32GB DDR5
Storage: Lexar NM620 2TB M.2 - (x2)
Mobo: MiniPC (Topton X6C )
Laptop: Lenovo Legion 5 Pro 16ITH6H /Ram32GB/ssd500GB/ssd1TB
Lisciu
Piegowaty Guziec
Piegowaty Guziec
Posty: 7
Rejestracja: 06 maja 2017, 14:31
Płeć: Mężczyzna
Wersja Ubuntu: 20.04
Środowisko graficzne: GNOME
Architektura: x86_64

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Lisciu »

kobrawerde pisze: 30 lis 2024, 10:58 Sam robiłem według tego tuto-riala więc na pewno nie jest to winowajca twoich problemów :-) ( no chyba że podczas robienia według tego zrobiłeś jakiś błąd ale tego teraz nie zweryfikujemy ) ... ewidentnie teraz system zgłupiał i podaje niepoprawne dane. Chyba coś jest pomieszane z montowanymi partycjami ?
Możesz porównać co pokazują pewne komendy z pod terminala w systemie:

Kod: Zaznacz cały

cd /
sudo du -sh * | sort -h

Kod: Zaznacz cały

sudo fdisk -l
partycja systemowa wielkość

Kod: Zaznacz cały

sudo du -xsh / | sort -h
zweryfikować wpisy w pliku fstab
Terminal zwraca takie wyniki:
pablo@Komputer:~$ cd /
pablo@Komputer:/$ sudo du -sh * | sort -h
[sudo] hasło użytkownika pablo:
du: nie ma dostępu do 'proc/3303/task/3303/fd/4': Nie ma takiego pliku ani katalogu
du: nie ma dostępu do 'proc/3303/task/3303/fdinfo/4': Nie ma takiego pliku ani katalogu
du: nie ma dostępu do 'proc/3303/fd/3': Nie ma takiego pliku ani katalogu
du: nie ma dostępu do 'proc/3303/fdinfo/3': Nie ma takiego pliku ani katalogu
du: nie ma dostępu do 'run/user/1000/doc': Brak dostępu
du: nie ma dostępu do 'run/user/1000/gvfs': Brak dostępu
0 bin
0 dev
0 lib
0 lib32
0 lib64
0 libx32
0 proc
0 sbin
0 sys
4,0K cdrom
4,0K mnt
4,0K srv
16K lost+found
96K tmp
2,1M run
2,5M root
13M etc
587M boot
1,6G opt
5,7G media
9,5G usr
20G var
37G snap
140G home
pablo@Komputer:/$


pablo@Komputer:/$ sudo fdisk -l
Dysk /dev/loop0: 249,8 MiB, bajtów: 261177344, sektorów: 510112
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop1: 4 KiB, bajtów: 4096, sektorów: 8
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop2: 55,68 MiB, bajtów: 58363904, sektorów: 113992
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop3: 103,102 MiB, bajtów: 109043712, sektorów: 212976
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop4: 104,2 MiB, bajtów: 109252608, sektorów: 213384
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop5: 63,10 MiB, bajtów: 67080192, sektorów: 131016
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop6: 63,71 MiB, bajtów: 66789376, sektorów: 130448
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop7: 74,25 MiB, bajtów: 77852672, sektorów: 152056
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/sda: 447,13 GiB, bajtów: 480103981056, sektorów: 937703088
Disk model: TEAM T253X1480G
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Typ etykiety dysku: dos
Identyfikator dysku: 0x686039ce

Urządzenie Rozruch Początek Koniec Sektory Rozmiar Id Typ
/dev/sda1 * 2048 104447 102400 50M 7 HPFS/NTFS/exFAT
/dev/sda2 104448 167774207 167669760 80G 7 HPFS/NTFS/exFAT
/dev/sda3 167774208 419430399 251656192 120G 7 HPFS/NTFS/exFAT
/dev/sda4 419434494 937701375 518266882 247,1G 5 Rozszerzona
/dev/sda5 419434496 619431935 199997440 95,4G 83 Linux
/dev/sda6 619433984 935702527 316268544 150,8G 83 Linux
/dev/sda7 935704576 937701375 1996800 975M 82 Linux swap / Solaris


Dysk /dev/sdb: 698,65 GiB, bajtów: 750156374016, sektorów: 1465149168
Disk model: ST750LM022 HN-M7
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 4096
Rozmiar we/wy (minimalny/optymalny) w bajtach: 4096 / 4096
Typ etykiety dysku: gpt
Identyfikator dysku: 916CDC14-A67F-11EF-9716-C01885B8167A

Urządzenie Początek Koniec Sektory Rozmiar Typ
/dev/sdb1 2048 1465147391 1465145344 698,7G Microsoft - dane podstawowe


Dysk /dev/loop8: 210,76 MiB, bajtów: 220975104, sektorów: 431592
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop9: 192,10 MiB, bajtów: 202350592, sektorów: 395216
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop10: 515,31 MiB, bajtów: 540332032, sektorów: 1055336
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop11: 73,9 MiB, bajtów: 77463552, sektorów: 151296
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop12: 55,37 MiB, bajtów: 58052608, sektorów: 113384
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop13: 515,69 MiB, bajtów: 540721152, sektorów: 1056096
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop15: 218,4 MiB, bajtów: 228999168, sektorów: 447264
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop14: 164,84 MiB, bajtów: 172830720, sektorów: 337560
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop16: 164,84 MiB, bajtów: 172830720, sektorów: 337560
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop18: 504,16 MiB, bajtów: 528642048, sektorów: 1032504
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop19: 505,9 MiB, bajtów: 529625088, sektorów: 1034424
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop17: 218,4 MiB, bajtów: 228999168, sektorów: 447264
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop20: 349,71 MiB, bajtów: 366678016, sektorów: 716168
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop21: 140 KiB, bajtów: 143360, sektorów: 280
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop22: 349,71 MiB, bajtów: 366682112, sektorów: 716176
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop23: 91,7 MiB, bajtów: 96141312, sektorów: 187776
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop24: 81,27 MiB, bajtów: 85209088, sektorów: 166424
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop26: 2,4 GiB, bajtów: 2191425536, sektorów: 4280128
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop25: 443,23 MiB, bajtów: 464756736, sektorów: 907728
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop28: 2,4 GiB, bajtów: 2191425536, sektorów: 4280128
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop27: 920 KiB, bajtów: 942080, sektorów: 1840
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop29: 920 KiB, bajtów: 942080, sektorów: 1840
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop30: 4,2 MiB, bajtów: 4395008, sektorów: 8584
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop31: 3,58 MiB, bajtów: 3735552, sektorów: 7296
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop32: 3,58 MiB, bajtów: 3735552, sektorów: 7296
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop33: 432,8 MiB, bajtów: 453062656, sektorów: 884888
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop34: 438,84 MiB, bajtów: 460136448, sektorów: 898704
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop35: 556 KiB, bajtów: 569344, sektorów: 1112
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop36: 556 KiB, bajtów: 569344, sektorów: 1112
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop38: 181,84 MiB, bajtów: 190648320, sektorów: 372360
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop37: 181,84 MiB, bajtów: 190652416, sektorów: 372368
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop39: 38,85 MiB, bajtów: 40714240, sektorów: 79520
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop40: 44,3 MiB, bajtów: 46448640, sektorów: 90720
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop42: 214,92 MiB, bajtów: 225341440, sektorów: 440120
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop41: 214,92 MiB, bajtów: 225337344, sektorów: 440112
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop43: 618,10 MiB, bajtów: 649039872, sektorów: 1267656
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop44: 52,78 MiB, bajtów: 55328768, sektorów: 108064
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop45: 28 KiB, bajtów: 28672, sektorów: 56
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop46: 99,48 MiB, bajtów: 104304640, sektorów: 203720
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop47: 453,6 MiB, bajtów: 475066368, sektorów: 927864
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop48: 346,96 MiB, bajtów: 363794432, sektorów: 710536
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop50: 500,22 MiB, bajtów: 524509184, sektorów: 1024432
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop49: 346,9 MiB, bajtów: 363724800, sektorów: 710400
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/loop51: 505,99 MiB, bajtów: 530546688, sektorów: 1036224
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512


Dysk /dev/sdc: 29,3 GiB, bajtów: 31457280000, sektorów: 61440000
Disk model: ProductCode
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Typ etykiety dysku: dos
Identyfikator dysku: 0x0024cb4f

Urządzenie Rozruch Początek Koniec Sektory Rozmiar Id Typ
/dev/sdc1 * 2048 61439999 61437952 29,3G c W95 FAT32 (LBA)
pablo@Komputer:/$

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=c7e53e78-81a1-4f43-ba03-d98dd3c4c20d / ext4 errors=remount-ro 0 1
# swap was on /dev/sda7 during installation
UUID=4af4d9e0-05d1-40c7-9ff3-7aed4decd8da none swap sw 0 0
UUID=23f7dea7-aad2-4f81-b1a8-6067e61f7a35 /home ext4 defaults 0 2

Dzięki
Awatar użytkownika
kobrawerde
Gibki Gibbon
Gibki Gibbon
Posty: 2199
Rejestracja: 10 wrz 2006, 16:00
Płeć: Mężczyzna
Wersja Ubuntu: 22.04
Środowisko graficzne: Cinnamon
Architektura: x86_64
Kontakt:

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: kobrawerde »

Ja bym posprawdzał także czy zgadzają się numerki odnośnie partycji UUID ...w pliku fstab bo tego nie robisz metodą kopiuj wklej z tutoriala ale wpisujesz sam ...

Kod: Zaznacz cały

sudo blkid
a ciekawe co pokazuje

Kod: Zaznacz cały

df -h
df -a

może jakieś duże pliki nieusunięte ?
https://unix.stackexchange.com/question ... have-500gb
https://opensource.com/article/18/7/how ... pace-linux
Serwer: LinuxMint/Ubuntu 22.04/HWE kernel/Vsftpd/Kodi/Jellyfin/iptv-dvbt2/etc.
CPU: Intel N100 / RAM: 32GB DDR5
Storage: Lexar NM620 2TB M.2 - (x2)
Mobo: MiniPC (Topton X6C )
Laptop: Lenovo Legion 5 Pro 16ITH6H /Ram32GB/ssd500GB/ssd1TB
Awatar użytkownika
Foka0111
Zakręcona Traszka
Zakręcona Traszka
Posty: 683
Rejestracja: 29 cze 2010, 01:18
Płeć: Mężczyzna
Wersja Ubuntu: 22.04
Środowisko graficzne: KDE Plasma
Architektura: x86_64
Kontakt:

Re: EXT4 kradnie miejsce na dysku defragmentacja?

Post autor: Foka0111 »

Albo ręcznie sprawdzić które katalogi zajmują tyle miejsca bo po zmianie dysku pewnie nie podałeś z palca w FSTAB UUID tego dysku zamiast starego więc kombinacji może być sporo. Np program do torrentów zaczął ściągać Ci jeszcze raz filmy itp.
ODPOWIEDZ

Wróć do „Przedszkole Linuksa”

Kto jest online

Użytkownicy przeglądający to forum: Amazon [Bot] i 18 gości