ext4 bölüm boyutu / boş alan tutarsızlıkları


14

Verilerim için 250GiB yedek bölüm oluştururken, bildirilen bölüm boyutu ile Nautilus, gParted, df, tune2fs vb.

İlk başta bunun bir GiB / GB karışıklığı olduğunu düşündüm. Öyle değildi .

Sonra ext4'ün ayrılmış blokları olabileceğini düşündüm. Öyle değildi .

Tamamen şaşkınım. İşte bazı görüntüler. İşte adımlar:

  • İlk olarak, NTFS. 524288000 sektör x 512 bayt / sektör = 268435456000 bayt = 268,4 GB = 250 GiB.

resim açıklamasını buraya girin resim açıklamasını buraya girin

Nautilus " Toplam Kapasite: 250.0 GB " diyor (aslında GB değil, GiB olmasına rağmen). Küçük etiketleme dışında, şimdiye kadar çok iyi

  • Şimdi, aynı bölüm, gparted ile ext4 olarak biçimlendirildi:

resim açıklamasını buraya girin

Birinci, Son ve Toplam sektörler aynı. Aynı 250GiB bölümüdür. Kullanılan boyut 4.11GiB'dir (ayrılmış bloklar belki?)

resim açıklamasını buraya girin

Hayır! Rezerve bloklar 12.7 GiB (~% 5. Ah! ). Ama ... Toplam Kapasite şimdi neden sadece 246.1 GiB ??? . Bu fark (bir çeşit), gparted tarafından bildirilen 4.11 GiB ile eşleşir. Ama ... eğer ayrılmış bloklardan değilse, nedir? Ve neden gparted 12.7GiB kullanılan alan bildirmedi?

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

dfbildirilen boş alanda Nautilus ile eşleşir. Ama .. sadece 188M mi kullanıldı? ~ 12GB olmamalı mı? Ve toplam kapasite hala yanlış. Yani ben koştum tune2fsbazı ipuçları bulmak için. (alakasız çıktı işlenir)

$ 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 toplam blok * 4096 bayt / blok = 268435456000 bayt = 268,4 GB = 250 GiB. Parlayan ile eşleşir.

3276800 ayrılmış blok = 13421772800 bayt = 13,4 GB = 12,5 GiB. Nautilus ile eşleşir (yine bir çeşit).

64459851 serbest blok = 264027549696 bayt = 264,0 GB = 245,9 GiB. Neden? 250-12.5 = 237.5 (veya 250- (12.5 + 4.11) = ~ 233) olmamalı mı?

Ayrılmış blokları kaldırma:

$ 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

Beklendiği gibi, aynı blok sayısı, 0 ayrılmış blok, ama ... aynı serbest bloklar ? 12.5 GiB'yi serbest bırakmadım mı?

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

resim açıklamasını buraya girin

Benim yaptığım gibi. Kullanılabilir alan 233'ten 245,9 GiB'ye yükseldi. gösteren hiç umursamadı Gparted'tan tam olarak aynı bilgi! (aynı ekran görüntüsünü yayınlamak işe yaramaz)

Ne büyük bir karmaşa!

Elimden geldiğince en iyi şekilde belgelemeye çalıştım ... Öyleyse, lütfen birisi bana burada neler olduğuna dair herhangi bir ipucu verebilir mi?

  • NTFS -> ext4 biçimlendirmesinde eksik olan bu 4.11 GiB nedir?
  • Neden gparted, Nautilus, tune2fs, df arasında bu kadar çok tutarsızlık var?
  • Matematiğimde yanlış olan ne? (koyu renkle yazılmış sorular bu gönderiyi dağıttı)

Herhangi bir yardım takdir. Neler olup bittiğini anlayamasam da, ext4'den benim / bölümüm dışındaki her şey için NTFS lehine vazgeçmeyi düşünüyorum.

Teşekkürler!




@Uri Herrera: sorumu ya da en azından ilk birkaç satırı gerçekten okudun mu? Bu değil bir GiB / GB sorunu. Bölme 268.4GB = 250.0GiB olduğu değil 246.1
MestreLion

1
Bir göz atabileceğiniz başka bir cevap: askubuntu.com/questions/5335/…
enzotib

Yanıtlar:


13

Burada birkaç şey oluyor. gparted gerçek kullanılan / boş alanı bildirir. Çekirdek, ayrılan alandaki kullanılabilir sayıyı azaltır. Ayrılmış alanı kaldırdıktan sonra, ayrılmış bloklar zaten ücretsiz olduğu için ücretsiz sayım değişmedi; sadece root olmayan kullanıcıların diski doldurarak sorun yaratmalarını önlemek için bu alanı işgal etmelerine izin verilmez. Gnome numaraları bir hata yüzünden biraz lapa lapa . Çekirdeğin rapor ettiği (ve df'nin gösterdiği) kullanılan alanı bildirmek yerine, boş alanı toplamdan çıkararak hesaplar. Bu, kullanılan ayrılmış alanı göstermesine neden olur.

Eksik 4GB aslında ext4 için fs yükü kullanılır. NTFS başlangıçta MFT için sadece az miktarda yer ayırır ve gerektiğinde büyütür. Ext dosya sistemleri serisi olsa da, biçimlendirme zamanında inode tablo (MFT kaba eşdeğeri) için yer ayırın ve büyüyemez. Bildirilen toplam alandan eksik olan boşluk inode tablosudur. Kullanılan alanın kalan biti dergiden (genellikle 128 mb) ve yeniden boyutlandırma düğümlerinden alınmıştır.


Bazı gizemleri çözdüğünüz için +1 teşekkürler! Ancak, ~ 4GB dosya sistemi yükü ise, neden 188MB gerçekte kullanıldığını gösterirken, bir kısmı (3.9GB) toplam alandan çıkarılır? Hangi yük (veya her ikisi) yüktür? Ve neden farklı muamele ettiniz? Ayrıca, dfsudo ile bile, Nautilus gibi toplam kapasite (247GB) ve kullanılan alan (188MB) gösterir. Yani bu bir hata ise, sadece gnome değil.
MestreLion

Ben 188MB yükü olduğunu düşündüm (NTFS 72MB ile karşılaştırıldığında). Ancak, NTFS yükü bir süre sonra büyüyecekse, bu Nautilus'un daha sonra toplam kapasitesinin daraldığını bildireceği anlamına mı geliyor?
MestreLion

Düzeltme: df, kim çalıştırırsa çalıştırsın daima kullanılabilir alanı gösterir. Boş alanı görmek için (== kullanılabilir alan + ayrılmış alan) kullanın stat -f /media/BACKUP.
Marius Gedminas

Açıklamak için cevap düzenlendi. Ve NTFS'nin MFT büyüdükçe toplamı küçültmek yerine sadece daha fazla kullanılan alan bildireceğine inanıyorum. @Marius, bu da doğru değil. statfs () ve dolayısıyla hem df hem de stat -f, ayrılmış blokları saymayan kullanılabilir alanı gösterir. Ben de kota için ayarlanmış yemin olabilir ve yanıtını arayan kullanıcı dayalı çeşitli, ama haklısın; kotayı saymaz ve kullanıcının ne dediği umurunda değildir.
psusi

@psusi: Bu yüzden ~ 3.9GiB inode tablosu ve ~ 188MB günlük + bir şey var mı? Nautilus inode tablosunu Total Size'den çıkarırken, günlük kullanılan alan olarak rapor edilir mi? Ve gparted bunları tek bir 4.11GiB kullanılan alan olarak rapor eder? Bu doğru mu? Eğer öyleyse, Nautilus'un her iki yükü de aynı şekilde ele almasını diledim. Ya ikisi de toplamdan çıkarıldı ya da her ikisi de "kullanılmış alan" (tercihen) olarak sayıldı.
MestreLion

7

Her şeyden önce, ayrılmış bloklar dosya sistemi iç yönetimi için kullanılan blok değildir .

Ayrılmış bloklar, rootbu bölümdeki dosyaları kullanan hizmetlerin, tüm alanı dolduran yönetici olmayan bir kullanıcı tarafından alanın dışına alınamayacağından emin olmak için ayrılmıştır .

Ayrılmış bloklar ( -m 0) olmasa bile, dosya sistemi iç yönetimi için kullanılan alanın her zaman bir parçası olsa da, ne kadar derin bir bilgiye sahip olmadığımı söyleyemem.

Ayrıca, Gparted olarak yürütülür root, bu nedenle ayrılmış blokları ücretsiz olarak görür. Kullanıcı olarak yürütülen Nautilus , onları özgür olmayan olarak görür.

Tamam, @psusi cevabı çok açık, ekleyecek bir şeyim yok.


Humm, çok bilgilendirici, +1. En azından bu bulduğum bazı sorunları çözüyor. Ayrılmış blokları "kullanılmış bloklar" yerine kök olmayanlar için "sınırlama sınırı" olarak görmek, gparted, df ve tune2fs okumalarını kabul eder (ve anlamlı kılar). Ancak, hala 4GB kullanılan alan / toplam kapasite gibi bazı sorular hala devam etmektedir.
MestreLion

1
Ayrıca, kök için% 5 alan ayırmanın extN tahsis algoritmalarına biraz nefes alan sağladığını ve bu nedenle parçalanma.
Marius Gedminas

1

Parçalı kullanarak bölüm boyutunu birkaç megabayt azaltmayı ve sonra tekrar orijinal boyutuna yükseltmeyi deneyin. Bu, diğer uygulamaların boyutları doğru okumasına neden olabilir. Son zamanlarda bir 50Gb hatasını bu şekilde düzelttim!

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.