2 Eylül 2026 - 22:54
NFS Bağlantısı Takıldığında Ne Yapılır? Görseli
Sunucu Yönetimi

NFS Bağlantısı Takıldığında Ne Yapılır?

Yorumlar

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

BASH
grep ' nfs' /proc/self/mounts
grep -F '/mnt/arsiv' /proc/self/mountinfo
nfsstat -m

Örnek kayıt:

TEXT
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

BASH
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:

BASH
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

BASH
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:

BASH
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:

BASH
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:

BASH
findmnt -R /mnt/arsiv
sudo fuser -vm /mnt/arsiv

-f ve -l aynı işlem değildir

KomutDavranışSınır
umount -f /mnt/arsivErişilemeyen NFS için zorla ayırmayı denerTakılmayacağı garanti edilmez
umount -l /mnt/arsivMount’u dizin ağacından hemen ayırır; referansları daha sonra temizlerEski referanslar yaşamaya devam edebilir; yeniden başlatma planı gerekebilir
umount -fl /mnt/arsivForce 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

BASH
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.

Teknik başvuru: nfs(5) ve umount(8).

Benzer Yazılar

Yorumlar ()

Henüz yorum yok. İlk yorum yapan sen ol!

Yorum Yap