ukuran partisi ext4 / perbedaan ruang bebas

14

Saat membuat partisi cadangan 250GiB untuk data saya, saya perhatikan banyak perbedaan antara ukuran partisi yang dilaporkan dan ruang kosong di Nautilus, gParted, df, tune2fs, dll.

Pada awalnya saya pikir itu adalah kebingungan GiB / GB. Bukan itu .

Lalu saya pikir itu bisa menjadi blok cadangan ext4. Bukan itu .

Saya benar-benar bingung. Ini beberapa gambar. Berikut langkah-langkahnya:

  • Pertama, NTFS. 524288000 sektor x 512 byte / sektor = 268435456000 byte = 268,4 GB = 250 GiB.

masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini

Nautilus mengatakan " Total Kapasitas: 250.0 GB " (meskipun sebenarnya GiB, bukan GB). Terlepas dari kesalahan label kecil itu, sejauh ini, sangat bagus

  • Sekarang, partisi yang sama , diformat sebagai ext4 dengan gparted:

masukkan deskripsi gambar di sini

Sektor pertama, terakhir, dan total adalah sama. Ini adalah partisi 250GiB yang sama. Ukuran yang digunakan adalah 4,11GiB (blok yang dipesan mungkin?)

masukkan deskripsi gambar di sini

Nggak. Sepertinya blok yang dipesan adalah 12,7 GiB (~ 5%. Aduh! ). Tapi ... mengapa Total Kapasitas sekarang hanya 246,1 GiB ??? . Perbedaan itu (semacam) cocok dengan 4,11 GiB yang dilaporkan oleh gparted. Tapi ... jika bukan dari blok yang dipesan, apa itu? Dan mengapa gparted tidak melaporkan bahwa 12,7GiB ruang yang digunakan?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

dfcocok dengan Nautilus di ruang kosong yang dilaporkan. Tapi .. hanya 188M yang digunakan? Bukankah seharusnya ~ 12GB? Dan kapasitas total masih salah. Jadi saya berlari tune2fsuntuk menemukan beberapa petunjuk. (output yang tidak relevan dihilangkan)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 total blok * 4096 byte / blok = 268435456000 byte = 268,4 GB = 250 GiB. Ini cocok dengan gparted.

3276800 blok cadangan = 13421772800 byte = 13,4 GB = 12,5 GiB. Ini (sekali lagi, semacam) cocok dengan Nautilus.

64459851 blok gratis = 264027549696 byte = 264,0 GB = 245,9 GiB. Mengapa? Bukankah seharusnya 250-12.5 = 237.5 (atau 250- (12.5 + 4.11) = ~ 233)?

Menghapus blok yang dipesan:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

Seperti yang diharapkan, jumlah blok yang sama, 0 blok yang dipesan, tapi ... blok gratis yang sama ? Bukankah saya baru saja membebaskan 12,5 GiB?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

masukkan deskripsi gambar di sini

Sepertinya saya lakukan. Ruang yang tersedia naik dari 233 menjadi 245,9 GiB. gparted tidak peduli sama sekali, menampilkan info yang persis sama! (tidak berguna untuk mengirim tangkapan layar yang identik)

Benar-benar kekacauan besar!

Saya mencoba mendokumentasikannya sebaik mungkin ... Jadi, bisakah seseorang memberi saya petunjuk tentang apa yang terjadi di sini?

  • Apa itu 4.11 GiB hilang dari NTFS -> format ext4?
  • Mengapa ada begitu banyak perbedaan antara gparted, Nautilus, tune2fs, df?
  • Apa yang salah dengan matematika saya? (pertanyaan dalam huruf tebal tersebar di pos ini)

Bantuan apa pun dihargai. Meskipun saya tidak dapat mengetahui apa yang sedang terjadi, saya dengan serius mempertimbangkan untuk menyerah pada ext4 untuk NTFS untuk semuanya kecuali partisi / saya.

Terima kasih!

MestreLion
sumber
@Uri Herrera: apakah Anda benar-benar membaca pertanyaan saya, atau setidaknya beberapa baris pertama? Ini bukan masalah GiB / GB. Partisi adalah 268.4GB = 250.0GiB, bukan 246.1
MestreLion
1
Jawaban lain yang dapat Anda lihat: askubuntu.com/questions/5335/…
enzotib
1
Lihat juga ext4: Bagaimana cara memperhitungkan ruang sistem file?
Gilles 'SANGAT berhenti menjadi jahat'

Jawaban:

13

Ada beberapa hal yang terjadi di sini. gparted melaporkan ruang yang digunakan / kosong yang sebenarnya. Kernel mengurangi jumlah yang tersedia oleh ruang yang disediakan. Setelah Anda menghapus ruang yang dipesan, penghitungan gratis tidak berubah karena blok yang dipesan sudah bebas; hanya saja pengguna non root tidak diizinkan untuk menginvasi ruang itu untuk mencegah mereka menyebabkan masalah dengan mengisi disk. Angka gnome agak serpihan karena bug . Alih-alih melaporkan ruang yang digunakan yang dilaporkan oleh kernel (dan df ditunjukkan), ia menghitungnya dengan mengurangi ruang kosong dari total. Ini menyebabkannya menampilkan ruang yang dipesan saat digunakan.

4GB yang hilang sebenarnya digunakan adalah fs overhead untuk ext4. NTFS awalnya hanya mengalokasikan sejumlah kecil ruang untuk MFT, dan menumbuhkannya sesuai kebutuhan. Seri ext filesystems, mengalokasikan ruang untuk tabel inode (setara kasar MFT) pada waktu format dan tidak dapat tumbuh. Ruang yang hilang dari total ruang yang dilaporkan adalah tabel inode. Bit sisa ruang yang digunakan adalah dari jurnal (biasanya 128 mb) dan mengubah ukuran inode.

psusi
sumber
Terima kasih, +1 untuk memecahkan beberapa misteri! Tetapi, jika ~ 4GB adalah overhead sistem file, mengapa sebagian (3.9GB) dikurangkan dari total ruang, sementara 188MB ditampilkan sebagai benar-benar digunakan? Yang mana (atau keduanya) overhead? Dan mengapa ditangani secara berbeda? Juga,, dfbahkan dengan sudo, menunjukkan kapasitas total (247GB) dan ruang yang digunakan (188MB) seperti Nautilus. Jadi jika itu bug, itu bukan hanya gnome.
MestreLion
Saya pikir 188MB adalah overhead (dibandingkan dengan 72MB dari NTFS). Tetapi, jika overhead NTFS akan tumbuh setelah beberapa waktu, apakah itu berarti Nautilus nantinya akan melaporkan total kapasitasnya menyusut ?
MestreLion
Koreksi: df selalu menunjukkan ruang yang tersedia, tidak peduli siapa yang menjalankannya. Untuk melihat ruang kosong (== ruang yang tersedia + ruang yang dipesan), gunakan stat -f /media/BACKUP.
Marius Gedminas
Jawaban yang diedit untuk menjelaskan. Dan saya percaya bahwa NTFS hanya akan melaporkan lebih banyak ruang yang digunakan, tidak menyusut total seiring pertumbuhan MFT. @Marius, ini juga tidak benar. statfs () dan karenanya df dan stat -f keduanya menunjukkan ruang yang tersedia tidak termasuk blok yang disediakan. Saya berani bersumpah bahwa itu juga disesuaikan dengan kuota, dan memvariasikan responsnya berdasarkan pengguna panggilan, tetapi Anda benar tentang itu; itu tidak menghitung kuota dan tidak peduli apa yang disebut pengguna.
psusi
@psusi: jadi saya punya ~ 3,9GiB dari tabel inode, dan ~ 188MB jurnal + sesuatu? Dan Nautilus mengurangi tabel inode dari Total Size, sementara melaporkan jurnal sebagai ruang yang digunakan? Dan gparted melaporkannya sebagai ruang tunggal 4.11GiB yang digunakan? Apakah itu benar? Jika demikian, saya hanya berharap Nautilus menangani kedua overhead dengan cara yang sama .. baik dikurangkan dari total atau keduanya dihitung sebagai "ruang bekas" (lebih disukai).
MestreLion
7

Pertama-tama, blok yang dipesan bukan blok yang digunakan untuk manajemen internal sistem file.

Blok yang dicadangkan hanya dicadangkan root, untuk memastikan bahwa layanan yang menggunakan file pada partisi itu tidak dapat dikesampingkan oleh beberapa pengguna non-admin yang mengisi semua ruang.

Bahkan tanpa blok cadangan ( -m 0) selalu ada bagian dari ruang yang digunakan untuk manajemen internal filesystem, saya tidak bisa mengatakan berapa banyak, saya belum memiliki pengetahuan yang mendalam.

Juga, Gparted dieksekusi sebagai root, sehingga ia melihat blok yang dipesan sebagai gratis. Nautilus , dieksekusi sebagai pengguna, melihatnya sebagai tidak gratis.

Ok, jawaban @psusi sangat jelas, saya tidak perlu menambahkan.

enzotib
sumber
Humm, sangat informatif, +1. Setidaknya ini memecahkan beberapa masalah yang saya temukan. Melihat blok yang dipesan sebagai "batas batas" untuk non-root alih-alih "blok yang digunakan" membuat pembacaan gparted, df dan tune2fs setuju (dan masuk akal). Tetapi beberapa pertanyaan masih ada, khususnya ruang yang digunakan / kapasitas total 4GB.
MestreLion
1
Juga, saya telah membaca di suatu tempat (salah satu dari yang lama "mengapa Anda tidak perlu men-defrag partisi Linux Anda setiap bulan" HOWTO mungkin?) Bahwa pemesanan 5% ruang untuk root memberikan ruang bernapas untuk algoritma alokasi extN dan karenanya menghindari fragmentasi.
Marius Gedminas
1

Coba kurangi ukuran partisi dengan beberapa megabyte menggunakan gparted, lalu tambah lagi ke ukuran aslinya. Ini dapat menyebabkan aplikasi lain membaca ukuran dengan benar. Saya baru-baru ini memperbaiki kesalahan 50Gb dengan cara ini!

jim birch
sumber