NFS sunucusu yanıt vermediğinde basit bir ls /mnt/arsiv komutu bile terminali kilitlenmiş gibi gösterebilir. Aynı mount noktasına dokunan df, yedekleme, izleme ajanı ve uygulamalar da beklemeye girer. İlk amaç bağlantıyı hemen ayırmak değil; hangi komutların yeni I/O başlatacağını bilerek kanıt toplamaktır.
Mount noktasına dokunmadan bağlantıyı tanımlayın
grep ' nfs' /proc/self/mounts
grep -F '/mnt/arsiv' /proc/self/mountinfo
nfsstat -m
Örnek kayıt:
nfs01:/export/archive /mnt/arsiv nfs4 rw,relatime,vers=4.2,hard,proto=tcp,timeo=600,retrans=2 0 0
hard seçeneği NFS isteğini sunucu cevap verene kadar yeniden dener. Bu davranış veri bütünlüğünü korur; fakat sunucu veya ağ yolu uzun süre yoksa uygulama çağrıları bekler. timeo=600 TCP için 600 saniye değil, onda bir saniye birimiyle 60 saniyedir.
İsim çözümleme ile port erişimini ayırın
getent ahosts nfs01
ip route get 192.0.2.40
ping -c 2 192.0.2.40
nc -vz -w 3 192.0.2.40 2049
Ping kapalı olabilir; başarısız ping tek başına NFS’nin kapalı olduğunu kanıtlamaz. NFSv4 için asıl yol çoğunlukla TCP 2049’dur. NFSv3 kullanılıyorsa rpcbind, mountd ve sabitlenmemiş ek RPC portları güvenlik duvarı teşhisini genişletir:
rpcinfo -p 192.0.2.40
DNS adı birden fazla IP döndürüyorsa mount kaydının gerçekte hangi sunucuya bağlı olduğunu nfsstat -m ve bağlantı tablosuyla karşılaştırın.
D-State süreçlerini bulun
ps -eo state,pid,ppid,wchan:32,etime,comm,args | awk '$1 ~ /^D/'
sudo journalctl -k --since '-20 min' --no-pager | grep -iE 'nfs|rpc|blocked|not responding'
nfs_wait* veya rpc_* benzeri wait channel değerleri, süreçlerin NFS/RPC cevabı beklediğini düşündürür. D-State sürecine tekrarlanan kill -9 göndermek bağlantıyı düzeltmez; sinyal kernel beklemesi döndükten sonra işlenir.
Sunucu tarafını ayrı doğrulayın
NFS sunucusuna yönetim erişiminiz varsa istemciden bağımsız olarak servis ve export durumuna bakın:
sudo systemctl status nfs-server --no-pager
sudo exportfs -v
sudo ss -lntup | grep ':2049'
sudo journalctl -u nfs-server --since '-20 min' --no-pager
Servis çalışıyor görünürken arka uç disk, LVM, RAID veya başka bir NFS mount’u takılmış olabilir. Sunucudaki D-State süreçlerini ve kernel günlüğünü de kontrol edin. İstemciye cevap vermeyen süreç bazen ağ servisi değil export edilen depolamadır.
Normal ayırma için önce kullanıcıları durdurun
Sunucu geri geldiyse veya I/O yeniden akıyorsa bağlantıyı kullanan servisleri uygulama sırasına göre durdurun ve normal unmount deneyin:
sudo umount /mnt/arsiv
target is busy alırsanız sorun artık erişilemeyen sunucudan farklı olabilir. Çalışma dizini mount altında kalan kabuklar, açık dosyalar veya alt mount’lar vardır. Yol tekrar erişilebilir durumdaysa:
findmnt -R /mnt/arsiv
sudo fuser -vm /mnt/arsiv
-f ve -l aynı işlem değildir
| Komut | Davranış | Sınır |
|---|---|---|
umount -f /mnt/arsiv | Erişilemeyen NFS için zorla ayırmayı dener | Takılmayacağı garanti edilmez |
umount -l /mnt/arsiv | Mount’u dizin ağacından hemen ayırır; referansları daha sonra temizler | Eski referanslar yaşamaya devam edebilir; yeniden başlatma planı gerekebilir |
umount -fl /mnt/arsiv | Force ve lazy davranışını birleştirir | İlk seçenek değildir; açık yazmalar ve alt mount’lar değerlendirilmelidir |
Mutlak mount yolu kullanın. Sembolik link çözümleme işlemi erişilemeyen NFS üzerinde yeniden stat çağrısı oluşturabilir. Lazy unmount “veri güvenle yazıldı” anlamına gelmez; yalnızca namespace bağlantısını ayırır.
soft seçeneğini hızlı çözüm diye eklemeyin
soft veya softerr, yeniden deneme sınırından sonra uygulamaya hata döndürür. Linux NFS belgeleri, soft timeout’un belirli durumlarda sessiz veri bozulmasına yol açabileceği konusunda açıkça uyarır. Salt okunur, yeniden üretilebilir veri ile yazma ağırlıklı veritabanı veya yedekleme iş yükü için aynı seçim yapılmamalıdır.
Kalıcı yapılandırmayı değiştirmeden önce iş yükünün veri bütünlüğü gereksinimini, sunucu yedekliliğini ve uygulamanın I/O hatasına verdiği tepkiyi test edin. intr seçeneği modern çekirdeklerde eski davranışı geri getirmez; Linux 2.6.25 sonrasında yok sayılır.
Kurtarma sonrası kontrol
findmnt /mnt/arsiv
ps -eo state,pid,wchan:32,comm | awk '$1 ~ /^D/'
sudo journalctl -k --since '-5 min' --no-pager | grep -iE 'nfs|rpc|not responding'
timeout 5 stat /mnt/arsiv
findmnt beklenen sunucu ve seçenekleri gösteriyor, yeni D-State süreçleri oluşmuyor ve stat zaman aşımına uğramıyorsa istemci yolu tekrar kullanılabilir. Eski bloke PID’ler kaybolmadıysa onların wchan ve kernel stack bilgisi ayrı incelenmelidir.
Benzer Yazılar