EXT4 kradnie miejsce na dysku defragmentacja?
-
- 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?
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
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
-
- 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?
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:
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
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.
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
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
EDIT
W parametrze -m podajesz procent miejsca jaki ma być zarezerwowany np -m 3 ustawi że zarezerwowane pozostanie 3% miejsca.
-
- 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?
Dzięki za odpowiedź.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: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.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
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ę przezJeż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.Kod: Zaznacz cały
sudo tune2fs -m 0 /dev/tu_nazwa_urządzenia
EDIT
W parametrze -m podajesz procent miejsca jaki ma być zarezerwowany np -m 3 ustawi że zarezerwowane pozostanie 3% miejsca.
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
- jacekalex
- 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?
Zobacz, z konta root, wynik:
Wklej tutaj wyjście powyższego polecenia.
Kod: Zaznacz cały
fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
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
Komputer jest jak klimatyzacja - gdy otworzysz okna, robi się bezużyteczny...
Linux User #499936
Inny OS: Gentoo Linux

-
- 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?
Cześć. Dzieki za odzewjacekalex pisze: 26 lis 2024, 21:46 Zobacz, z konta root, wynik:Wklej tutaj wyjście powyższego polecenia.Kod: Zaznacz cały
fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
Kopiuje cale polecenie ale terminal zwraca mi to:
Dodam że wczesniej zrobiłem migracje /home na inna partycje i dlatego dziwi mnie to że Ubuntu 20.04 zjadło już 102GBpablo@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:~$

Ale program dyski pokazuje mi że mam nadal dostępne 67GB wolnego miejsca

- kobrawerde
- 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?
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 -ówDodam że wczesniej zrobiłem migracje /home na inna partycje i dlatego dziwi mnie to że Ubuntu 20.04 zjadło już 102GB
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
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
-
- 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?
kobrawerde pisze: 28 lis 2024, 18:56Moż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 -ówDodam że wczesniej zrobiłem migracje /home na inna partycje i dlatego dziwi mnie to że Ubuntu 20.04 zjadło już 102GB
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
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 wklej1. 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

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
- kobrawerde
- 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?
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:
partycja systemowa wielkość
zweryfikować wpisy w pliku fstab

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
Kod: Zaznacz cały
sudo du -xsh / | sort -h
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
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
-
- 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?
Terminal zwraca takie wyniki: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
partycja systemowa wielkośćKod: Zaznacz cały
sudo fdisk -l
zweryfikować wpisy w pliku fstabKod: Zaznacz cały
sudo du -xsh / | sort -h
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
- kobrawerde
- 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?
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 ...
a ciekawe co pokazuje
może jakieś duże pliki nieusunięte ?
https://unix.stackexchange.com/question ... have-500gb
https://opensource.com/article/18/7/how ... pace-linux
Kod: Zaznacz cały
sudo blkid
Kod: Zaznacz cały
df -h
df -a
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
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
- Foka0111
- 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?
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.
Kto jest online
Użytkownicy przeglądający to forum: Amazon [Bot] i 12 gości