Sunucu A, bir NFS sunucusu idi. Sunucu B bunun bir ihracatını hazırlıyordu. Herşey iyiydi. Sonra A öldü. Sadece kapattým. Gone. Kayboldu.
Ancak bu klasör hala B'ye bağlı. Açıkçası ona veya başka bir şeye
cd yapamıyorum. Ancak
umount /mnt/myfolder sadece kilitleniyor ve umount olmayacak. B'yi yeniden başlatmadan onu taklit etmek için yine de var mı?
Hem istemci hem de sunucu Linux makineleridir.
Linux varsayımı:
umount -f -l /mnt/myfolder
Sorunu çözecek:
-f Çıkarmayı zorla (erişilemeyen bir NFS sistemi olması durumunda). (2.1.116 veya sonraki bir çekirdek gerektirir.)
-l Tembel bağlantısını kesin. Dosya sistemini şimdi dosya sistemi hiyerarşisinden ayırın ve artık meşgul olmaz dosya sistemine yapılan tüm başvuruları temizleyin. (2.4.11 veya daha yeni bir çekirdek gerektirir.)
-f ayrıca Solaris ve AIX'te de bulunur.
İpucu üzerine detaylandırma David Pashley tarafından verilen ,
"umount -l" sorununuzu çözmedikçe, ortadan kaybolan adresle aynı adrese sahip sahte bir sunucu kurabilirsiniz - but yeni bir kurulum yapmanız gerekmez sever ya da herhangi bir şey. Engelleme/asılı umount durumundan çıkmanın en kolay yolu aşağıdaki gibi bir yerel takma IP arabirimi oluşturmaktır:
ifconfig eth0:nfstmp 22.214.171.124 netmask 255.255.255.255 umount -l /mnt/deadnfsmount # -l or -f or whichever that gets the job done ifconfig eth0:nfstmp down
(açıkçası 126.96.36.199 (şimdi ölü) NFS sunucusunun (eski) IP adresidir)
intr seçeneğini, asılı veya çökmeye neden olabilecek tüm
/etc/fstab Girişlerine eklemek akıllıca olabilir.
soft veya
intr seçeneklerini kullanmazsanız, NFS dosyalarını barındıran sunucu çöktüğünde, dosyaların açıldığı sunucu (istemci) önyükleme sırasında askıda kalabilir .
man 5 nfs Uyarınca:
yumuşak/sert
Bir NFS isteği zaman aşımından sonra NFS istemcisinin kurtarma davranışını belirler. Her iki seçenek de belirtilmezse (veya sabit seçenek belirtilirse), NFS istekleri süresiz olarak yeniden denenir. Yazılım seçeneği belirtilirse, yeniden iletim yeniden gönderimleri gönderildikten sonra NFS istemcisi bir NFS isteğini başarısız ederek NFS istemcisinin çağıran uygulamaya bir hata döndürmesine neden olur.
... ve daha sonra
intr'ın
soft yerine tercih edildiğini söylemeye devam ediyor, ancak asılı kalmayı önlemeye benzer bir etkiye sahip.
umount -f /mnt/myfolder bunu çözmeli. Umount kılavuzuna bakın.
Solaris için, NFS istemcisinin yeniden başlatılması "ölümcül sabit spiral" i çözecektir. Solaris 10 için komut "svcadm restart network/nfs/client" Son zamanlarda bunu bir Linux kutusunda denemedim (çünkü hepsi "intr" bayrağıyla bağlandığından, bu sorunu nadiren çözüyorlar), ancak muhtemelen de sorun.
Asla _ almayı başaramadım
umount -f çalışmak. Yararlı bir hile, aynı dışa aktarmayı bağlayan başka bir sunucu kurmak, eski sunucu ile aynı IP adresini vermektir. NFS istemciniz her şeyin normal gibi olduğunu ve işlemlerin engellemesini kaldıracağını düşünmelidir. Daha sonra bağlama noktasını normal olarak çıkarabilir ve IP adresini geçici NFS sunucusundan kaldırabilirsiniz.
Bir kenara, automount kullanmak, kullanılabilir hale geldiklerinde NFS paylaşımlarının bağlantısını kesecek ve bu durumda gelecekte sıkışmayacak.
Ben de aynı problemle karşılaştım. NFS sunucusu kaldırıldığından, nfs'yi istemciden ayıramıyorum. Aşağıdaki hileyi denedim, faydalı olup olmadığına bakın. Orijinal NFS sunucusu gittiğinden, aynı IP ve dışa aktarma özelliklerine sahip yeni bir sunucu oluşturuyorum. Sonra umount -f/mnt/nfs_part komutunu denerim. Sonunda nfs şimdi umount olabilir.
mount komutları çoğunlukla * nix agnostik olduğu için yalnızca OS X'e özgü bir takip: OS X'te -l (tembel) bayrağı yoktur, ancak -f (kuvvet) bayrağı yapar ve yeterli olduğu kanıtlanmıştır . Ayrıca, sistem tarafından oluşturulan bağlama noktaları/Volumes (/ Volumes/myserversexport)
Çekirdek 3.2.0'daki zorla çıkarmanın NFSv4 bağlarında asılı olduğunu fark ettim. NFSv3 bağlantısının kesilmesi iyi çalışır.
$ mount [...] -o nfsvers=3