Sorun Giderme · Linux ve Sistem Yönetimi
Dosya Silindi ama Disk Doluluk Değişmedi: df ve du Teşhisi
Linux’ta dosya adını silmek açık file descriptor’ı kapatmaz. Son link kaldırılmış olsa da süreç dosyayı açık tutuyorsa alan kullanılmaya devam edebilir. df filesystem tahsisini, du…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Linux’ta dosya adını silmek açık file descriptor’ı kapatmaz. Son link kaldırılmış olsa da süreç dosyayı açık tutuyorsa alan kullanılmaya devam edebilir. df filesystem tahsisini, du erişebildiği isimler altındaki kullanımı ölçer; bu nedenle sonuçları farklı olabilir.
Önce doğru mount noktasını ve inode doluluğunu kontrol edin. lsof +L1 açık ama linksiz dosyaları gösterir; yetki veya namespace nedeniyle eksik sonuç olabilir. Snapshot, reserved blocks ve farklı mount altında gizlenen dosyalar da df/du farkı yaratabilir.
Üretim process’ini rastgele öldürmeyin veya /proc/PID/fd dosyasını kör truncate etmeyin. Uygulamanın desteklenen log reopen/reload veya kontrollü restart yöntemiyle descriptor’ı kapatın. Logrotate yapılandırmasının tekrar aynı arızayı üretmediğini test edin.
- 1df/du farkı
- 2Mount/inode kontrolü
- 3Açık linksiz descriptor
- 4Kontrollü reopen ve retest
Tasarım parametreleri
- Mount sınırı
- du -x ile tek filesystem içinde kalın; container mount namespace’lerini dikkate alın.
- Descriptor sahibi
- PID, servis, dosya boyutu ve bağlantı sayısını birlikte kaydedin.
- Inode
- Boş GB olsa da inode tükenmesi yazmayı durdurabilir; df -i kontrolü ayrı gereklidir.
Hesap ve uygulama örneği
Bir lab process’i 5 GB log dosyasını açık tutsun; pathname silinince du 5 GB azalırken df değişmeyebilir. Desteklenen reopen sonrası descriptor kapanırsa alan geri gelir. Aynı davranışı gerçek log rotation penceresinde doğrulayın.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
df -hT
df -i
du -xsh /var/log
sudo lsof +L1
# Use the owning application’s supported reopen/reload procedure after review.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| du küçük, df büyük | Açık silinmiş dosya veya snapshot. | lsof +L1 ve filesystem snapshot kullanımını inceleyin. |
| GB boş ama yazma hatası | Inode veya quota tükenmesi. | df -i ve kullanıcı quota’sını kontrol edin. |
Kabul ve doğrulama kontrolleri
- Doğru mount noktasını doğrulayın.
- Inode kullanımını ölçün.
- Descriptor sahibini bulun.
- Uygulamanın reopen yöntemini kullanın.
- df/du’yu tekrar ölçün.
- Log rotation’ı retest edin.
İlgili kavramlar
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.