Ek dosya sistemlerini Linux'ta kendileri için daha az alan kullanmanın bir yolu var mı?

Bir Linux sisteminde kullandığım bir sürü harici ve dahili HDD'm var. Sadece Linux sistemim var, bu yüzden bir Linux dosya sistemi kullanmak sadece mantıklı olur, değil mi? Ancak şu anda her yerde NTFS kullanıyorum, çünkü bana HDD'lerden en fazla kullanılabilir alanı veriyor.

Şu anda, çoğunlukla izinler ve uyumluluk nedeniyle Linux dosya sistemlerine geçmek istiyorum (örneğin, LUKS şifreli NTFS bölümünü Linux altında yeniden boyutlandırmak için alamıyorum, Windows altında chkdsk'e söylemeye devam ediyor).

Ancak bu HDD'leri biçimlendirdiğimde, bir sürü farklı dosya sistemi ve her Linux dosya sistemini denedim, bildiğim kadarıyla günlük kaydı olmayan ext2 bile kendisi için çok fazla alan kullandı. Kesin değerleri hatırlamıyorum ama NTFS beni 2TB'lik bir sabit disk sürücüsünde daha fazla elde etmişti.

Öyleyse benim sorum şu: Eklenti sistemlerini kendileri için daha az alan kullanmanın bir yolu var mı? Ya da başka bir dosya sistemi var (ext2, ext3, ext4, NTFS ve vfat denedim - hiçbiri mükemmel Linux desteği ve harika bir kullanılabilir alanla NTFS'nin bana sunduğu kullanılabilir alana bile yaklaşmadı)?

Dosya sistemlerinin (özellikle de günlük kaydı olmayan ext2) neden NTFS'den daha fazla yer kullandığını ve başka bir yere sormam gerektiğini bilmiyorum. Çoğunlukla ext4'ü günlüğe kaydetmeden ve bu kadar yer kaplayan herhangi bir şeyi mümkünse kullanmayı tercih ederim.

— konfeti
kaynak

Bu konuyu gördün mü ?

— JakeGould

Ben var, ve bu ekstra alanı neyin kullandığını açıkladı ama NTFS ile ext arasındaki fark reiserfs ve ext ile karşılaştırıldığında çok daha büyük ve merak etmenin daha küçük bir yolu olup olmadığını merak ediyorum. Örneğin bir 1TB HDD’de NTFS ile 989GB kullanabiliyorum. ext4 bana 909GB civarında verirdi.

— konfeti

Yeterince adil. İyi bir soru ve cevap da aydınlatıcıdır.

— JakeGould

hangi alanın mevcut olduğunu nasıl ölçersiniz? bu önemlidir, çünkü hangi değerlere baktığınıza bağlı olarak, örneğin% 5 rezervasyonun bağlantısını, örneğin bağlantılı soruda belirtildiği gibi görebilirsiniz

— eMBee,

Ext3 ve ext4 gibi dosya sistemlerinde günlük tutmanın iyi bir şey olduğunu unutmayın. Harici bir sürücüye güç vermek veya bir USB ise kazayla fişini çekmek oldukça kolaydır, Bu gerçekleştiğinde, çoğu zaman önemli değildir çünkü tekrar başladığında günlüğü kullanarak kendini iyileştirir. Bu güvenlik ağı olmadan işler çok daha kötü olurdu. Daha iyi bir durum değil.

— Joe

Yanıtlar:

Varsayılan olarak, ext2 ve halefleri, kök kullanıcı tarafından kullanılmak üzere dosya sisteminin% 5'ini ayırır. Bu, parçalanmayı azaltır ve yöneticinin ya da köke ait herhangi bir ödemenin çalışabileceği yer kalmaması olasılığını azaltır.

Bu ayrılmış bloklar, root olarak çalışmayan programların diskinizi doldurmasını önler. Bu hususların kapasite kaybını haklı gösterip göstermemesi, dosya sisteminin ne için kullanıldığına bağlıdır.

1980'lerde% 5'lik miktar disklerin çok daha küçük olduğu, ancak olduğu gibi bırakıldığı zaman belirlendi. Günümüzde sistem kararlılığı için% 1 muhtemelen yeterlidir.

Rezervasyon -m, tune2fskomut seçeneği kullanılarak değiştirilebilir :

tune2fs -m 0 /dev/sda1

Bu ayrılmış blok yüzdesini% 0 (0 blok) olarak ayarlayacaktır.

Geçerli değeri elde etmek için (diğerleri arasında), aşağıdaki komutu kullanın:

tune2fs -l <device>

— harrymc
kaynak

Bu, kullanılabilir alandaki muazzam farkı mükemmel şekilde açıklar (2 TB'ın% 5'i 100 GB olduğundan). Diskler, kök veya sistem dosyasıyla ilgili hiçbir şey için kullanılmayacaktır, bu yüzden bunu devre dışı bırakmanın saklanacağını düşünüyorum. Yine de bir sorum var: Köke ait programlar kök olmayan programlardan daha fazla boş alan olduğunu nasıl biliyor? Koşu dfhiçbir fark olmayan kök vs kök gösterildiği gibi.

— konfeti

@confetti: VFS bir hata ile diske yazma için girişimlerini reddetmez Çünkü (hacim kadar aslında tabii ki, tam).

— Ignacio Vazquez-Abrams

tune2fs -l <device>bu değeri diğerleri arasında vermelidir. 1980'lerde% 5'lik miktar disklerin çok daha küçük olduğu, ancak olduğu gibi bırakıldığı zaman belirlendi. Günümüzde sistem kararlılığı için% 1 muhtemelen yeterlidir.

— harrymc

XFS,% 5 veya 8192 bloktan (32 MiB) daha küçük olanı saklar, bu nedenle ayrılmış miktar, dosya sisteminin boyutuna göre genellikle çok küçüktür.

— Michael Hampton,

Açıklamalar için herkese çok teşekkür ederim. Bu beni çok iyi anlamama yardımcı oldu. Diskim önceki son baytını tamamen dolduruyordu, ancak sistemim tamamen başarısız olmadı, şimdi nedenini anlıyorum.

— konfeti

Eğer depolamak istediğiniz veri sıkıştırılabilir ise, compress=zstd(veya compress-force=zstd) ile monte edilen btrfs muhtemelen ext * 'den daha az disk alanı kullanır.

bu, btrfs'nin verilerinizi diske yazmadan önce şeffaf bir şekilde sıkıştırmasını ve geri okurken şeffaf bir şekilde açılmasını sağlar. Ayrıca, ext4 dosya sistemindeki tüm düğümleri önceden tahsis eder, btrfs bunları gerektiği gibi oluşturur, sanırım bu da biraz yer kazandırabilir.

— hanshenrik
kaynak

Bu cevaba daha fazla bilgi ekler misiniz? (Nasıl çalışır, ne yapar, belki bir referans, ...)

— konfeti,

@confetti böyle mi? patchwork.kernel.org/patch/9817875

— hanshenrik

Bu fikri gerçekten sevdim, ancak bunun hızı ve performansı nasıl etkileyeceği ve bunun iyi olacağı hakkında daha fazla bilgi.

— konfeti

@confetti, bir sabit disk kullandığınız için muhtemelen performansı artıracaktır. CPU'lar sabit disklerden çok daha hızlıdır; disk erişiminin yavaş kısmı verileri diskten açıp kapamaktadır; Sıkıştırmak veya açmak için harcanan zaman fark edilmeyecektir.

— Mark

Öte yandan, günümüzde çoğu büyük dosya türü (örneğin, görüntüler, ses, video, hatta çoğu zengin metin belgesi biçimleri) zaten sıkıştırılmış olma eğilimindedir ve genellikle ek sıkıştırma işleminden yararlanmaz. En azından dosya sistemi düzeyinde gerçekleştirilen basit genel amaçlı türde.

— Ilmari Karonen

Henüz konuşulmamış bir diğer nokta, dosya sisteminizde ayırdığınız inode sayısıdır.

Varsayılan olarak, mkfs dosya sisteminize bir çok küçük dosyayı yerleştirmeyi mümkün kılan bir dizi düğüm oluşturur. Dosyaların çok büyük olacağını ve FS'ye yalnızca az sayıda dosya koyacağınızı biliyorsanız, düğüm sayısını azaltabilirsiniz.

Kendine iyi bak! Bu sayı (sırasıyla boşluk ve düğüm sayısı arasındaki oran) yalnızca dosya sistemi oluşturma zamanında belirlenebilir. FS genişletilirken bile, oran aynı kalır.

— glglgl
kaynak

Alternatif olarak, çok sayıda küçük dosya saklayacağınızı biliyorsanız, inode sayısını artırabilir ve blok boyutunu azaltabilirsiniz, böylece çok fazla boşa harcamazsınız. (Her bir dosya en az bir blok tüketmelidir, 1 byte olsa bile. Diskte kullanılan ile boyutlarını karşılaştırmak için ls -ls kullanın.)

— Perkins

@Perkins Haklısın, ama bence bu sadece ÇOK küçük dosyalar için geçerli: varsayılan blok boyutu 4kiB (IIRC), en az bir tanesi 1 kiB. Bu yüzden kazanmak için çok fazla değil, diskiniz gerçekten bu dosyalarla dolu. Fakat yine de, yarın buna dalabilirim.

— glglgl

veya alternatif olarak, gerektiğinde inode oluşturan btrfs kullanın. ext4'ün inode'ları dosya sistemi oluşturma zamanında tahsis edilirken ve 4 milyarlık bir sabit limitle oluşturulduktan sonra yeniden boyutlandırılamazken, btrf'lerin inode'ları gerektiğinde dinamik olarak oluşturulur ve sabit limit 2 ^ 64'tür, 18.4 litre, yaklaşık 4.6 milyar

— max. ext4'ün

Bana usenet makarası ayarlamamı hatırlatıyor. ext4, inode'un kendisinde minik (en çok 60-160 byte'lık bir yere sahiptir) depolayacaktır.

— mr.spuratic

@hanshenrik btrfs üzerinde aynı blok boyutu sınırlamasının bulunduğunu (bununla çalışmak için birkaç ekstra yolla) olduğunu unutmayın; bu nedenle ne tür dosyaları (büyük veya küçük veya her ikisi) saklayacağınızı bilmeniz gerekir ve maksimum depolama alanını sıkıştırmak istiyorsanız, dosya sisteminizi uygun şekilde ayarlayın. Otomatik sıkıştırmanın kullanılabilirliği, kabarık verileri depolarsanız da biraz yardımcı olur.

— Perkins,