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:
- Burada ne oluyor? Boşluk neden silinirken hemen yerine umount veya gecikme ile serbest bırakılır?
- Şu anda bağlantıyı kesmeden ve yeniden monte etmeden alanı boşaltmak için yapabileceğim bir şey var mı ?
lsof | grep -i deleted
genellikle bunu kontrol etmenin en iyi yoludur.