Çok sayıda büyük dosyayı sildikten sonra, büyük bir gecikmeyle boş alan artar


15

Dün, ev / medya sunucumdaki 71 GB'lık dosyaları sildim.
Önce Boş Alan: 117 GB
Sonra Boş Alan: 126 GB

Yani, 71 GB ek boş alan yerine, sadece 9 GB'ım vardı. Hiçbir dosyanın açık olmadığını iki kez kontrol ettim ve gerçekten 71 GB'ı sildim ve boş alan gerçekten sadece 9 GB arttı.

Ayrıca senkronize etmeye çalıştım, ancak hiçbir etkisi olmadı.

Bu ilk kez gerçekleşmiyor. Gerçekten de, bu davranışı yıllar sonra görüyorum. İlk olarak ext3'te, şimdi ext4'te.
Bu olduğunda, dosya sistemini çıkarıp yeniden takarak boş alanı geri alabilirim. Bu durumlarda, sökme işlemi neredeyse hiç zaman yerine 2 dakika sürer.

Günümüzde dosya sistemini kolayca sökemiyorum ve yeniden monte edemiyorum, çünkü video kayıt yazılımımdan, ailem için kendi sunucum sunucusundan ve şu ana kadar sahip olmadığım birkaç hizmetten kalıcı olarak meşgul. Ve gece saat 3'te kalkmak istemiyorum, sadece söküp tekrar takmak için.

Hayır, 'at' yardımcı programı işe yaramaz çünkü hizmetlerden biri sürdürülemez uzun çalışan görevleri gerçekleştirir ve bu nedenle kapatılabileceği iyi bir anı bulmak için manuel durum kontrolüne ihtiyaç duyar, yani bir görev yeni bitmiştir.

Ama bu sabah, alanın bir gecede boşaltıldığını fark ettim. Bana bir çeşit temizlik varmış gibi görünüyor ve bu, bağlantıyı keserken ek zaman alan aynı şey olabilir.

Şimdiye kadar, bu davranışı sadece büyük miktarda veri silerken fark ettim. Öte yandan, düzenli olarak gerçekleşip gerçekleşmediğinden ve farkın fark edilemeyecek kadar küçük olduğundan emin değilim.

Dosya sistemi% 0 root ( mkfs -m 0) için ayrılmıştır . Göre fsck -f, dosya sistemi bozuk olmadığından (bu her zaman devreden çıkarılırken ve remount arasındaki yapıyorum) ve testi genişletilmiş SMART teşhis göre donanım da sorun yok.

[DÜZENLE]

tune2fs 1.42 (29-Nov-2011)  
Filesystem volume name:   bigdata  
Last mounted on:          /bigdata  
Filesystem UUID:          6aebd17a-e064-41dc-9c68-c9a3acbe4f66  
Filesystem magic number:  0xEF53  
Filesystem revision #:    1 (dynamic)  
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize  
Filesystem flags:         signed_directory_hash   
Default mount options:    user_xattr acl  
Filesystem state:         clean  
Errors behavior:          Continue  
Filesystem OS type:       Linux  
Inode count:              121413632  
Block count:              485645568  
Reserved block count:     0  
Free blocks:              29081276  
Free inodes:              121382378  
First block:              0  
Block size:               4096  
Fragment size:            4096  
Reserved GDT blocks:      908  
Blocks per group:         32768  
Fragments per group:      32768  
Inodes per group:         8192  
Inode blocks per group:   512  
Flex block group size:    16  
Filesystem created:       Tue Dec 25 23:42:35 2012  
Last mount time:          Fri Jan  3 17:37:36 2014  
Last write time:          Fri Jan  3 17:37:36 2014  
Mount count:              37  
Maximum mount count:      -1  
Last checked:             Thu Apr 18 17:03:40 2013  
Check interval:           0 (<none>)  
Lifetime writes:          14 TB  
Reserved blocks uid:      0 (user root)  
Reserved blocks gid:      0 (group root)  
First inode:              11  
Inode size:           256  
Required extra isize:     28  
Desired extra isize:      28  
Journal inode:            8  
Default directory hash:   half_md4  
Directory Hash Seed:      be2b977e-5127-4843-9123-fe33b6d7b573  
Journal backup:           inode blocks  

[/DÜZENLE]

İşte benim 2 sorum:

  1. Burada ne oluyor? Boşluk neden silinirken hemen yerine umount veya gecikme ile serbest bırakılır?
  2. Şu anda bağlantıyı kesmeden ve yeniden monte etmeden alanı boşaltmak için yapabileceğim bir şey var mı ?

Bu bana dosya (lar) hala bir şey tarafından açık gibi çok kokuyor. Silindikten sonra hiçbir dosyanın açık olmadığını nasıl doğrularsınız? lsof | grep -i deletedgenellikle bunu kontrol etmenin en iyi yoludur.
Garrett

2
Normalde dosyalar açıkken bir dosya sistemini takamazsınız. Yani, umount başarılı olursa, açık dosya yoktur. Dün hariç, bunu fark ettiğimde her zaman umount, yeniden montaj döngüsünü yaptım.
Markus N.

Gerçekten de durum böyle. Ext4 montaj seçenekleriniz nelerdir?
Garrett

noatime, defanslar
Markus N.14

Dosyaların kopyalarını tutabilecek veya alternatif olarak onlara sabit olabilecek bir tür yedekleme sisteminiz var mı?
derobert

Yanıtlar:


9

Etkileşimde olabilecek iki faktör vardır.

  • Windows'tan farklı olarak, açık dosyaları silebilirsiniz. Akış halindeki bir filmi silerseniz, dizinden kaldırılır, ancak akış programı kapatılıncaya kadar dosya olarak kalır. Akış yazılımı kapatıldıktan sonra alan serbest bırakılacaktır. fuser -mKomut açık dosyaları ile herhangi işlemlerin işlem kimliği bulmak için kullanılabilir. Bazı programlar, dosyalar tamamlandığında dosyaları hemen kapatamayabilir.

  • Bunların her ikisi de günlüklü dosya sistemleridir. Değişiklikler bir dergiye yazılır ve sonra işlenir. Değişikliklerin uygulanması biraz zaman alabilir. İşletim sistemi genellikle disk değişikliklerini önbelleğe alır ve diskte yalnızca düzenli aralıklarla değişiklik yapar. syncKomutun çalıştırılması, diskte bekleyen değişiklikleri temizlemelidir. Diskin bu syncseçenekle takılması, diskin hızını artıracak, ancak diski daha sıkı çalışacaktır.


1
Açık olan dosyaları silebileceğimi biliyorum. Dizin girişleri ve inode'lar arasındaki ilişkileri biliyorum. Ama eminim dosyalar açık değil, aksi takdirde dosya sistemini taklit edemezdim ... Ama ikinci öğeniz ilginç görünüyor. Silinen dosyaların işlenmesi gerçekten 30 dakikadan fazla sürebilir mi? 30 dakika, dosyaları silmek ve dünden önceki gün yatmak arasındaki süredir, bu yüzden gerçekten ne kadar sürdüğünü söyleyemem.
Markus N.

1
@MarkusN. Bazı işletim sistemleri çok sayıda dosya sistemi verisini önbelleğe alır. Alan gerekli değilse, alanın boşaltılmasını sağlamak için yeterli işlem günlüğü verileri yazabilirler, ancak alanı boşaltmak için zaman ayırırlar. Bir USB anahtarını çok fazla veri yazdıktan sonra çıkarırsanız, çıkarmadan önce verilerin temizlenmesi uzun sürebilir. Güvenli bir şekilde diske yazma ile diğer işlemleri geciktirmeme arasında bir değiş tokuştur.
BillThor

Düzenleme için teşekkürler. Ama asıl sorumda gördüğünüz gibi, senkronizasyonu zaten etkisiz denedim.
Markus N.

1
@MarkusN. Senkronizasyonun eskisi kadar etkili olduğunu düşünmüyorum. Muhtemelen sadece günlük verilerinin yazılmasını sağlar, tüm değişikliklerin yapılması gerekmez. Çıkar / tak, derginin uygulanmasını zorlar. Silme işlemlerinin zamanlama önceliğini bilmiyorum, ancak nispeten düşük olmasını beklerim. Kodu keşfetmek daha fazla sorunuza cevap verebilir.
BillThor

Bana mantıklı geliyor.
Markus N.
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.