„Stale uchwyt pliku NFS” po ponownym uruchomieniu

W węźle serwera można uzyskać dostęp do wyeksportowanego folderu. Jednak po ponownym uruchomieniu (zarówno serwera, jak i klienta) folder nie jest już dostępny dla klientów.

Na serwerze

# ls /data
Folder1
Forlder2

a plik / etc / export zawiera

/data 192.168.1.0/24(rw,no_subtree_check,async,no_root_squash)

Na kliencie

# ls /data
ls: cannot access /data: Stale NFS file handle

Muszę powiedzieć, że nie było problemu z udostępnionym folderem po stronie klienta, jednak po ponownym uruchomieniu (serwer i klient) widzę ten komunikat.

Jakiś sposób to naprawić?

Kolejność restartów jest ważna. Ponowne uruchomienie serwera po tym, jak klienci mogą spowodować taką sytuację. Nieaktualny uchwyt NFS wskazuje, że klient ma otwarty plik, ale serwer nie rozpoznaje już uchwytu pliku. W niektórych przypadkach NFS wyczyści swoje struktury danych po upływie limitu czasu. W innych przypadkach konieczne będzie samodzielne wyczyszczenie struktur danych NFS, a następnie zrestartowanie NFS. Gdzie te struktury się znajdują, są nieco zależne od O / S.

Spróbuj ponownie uruchomić NFS najpierw na serwerze, a następnie na klientach. Może to wyczyścić uchwyty plików.

Ponowne uruchomienie serwerów NFS z plikami otwartymi z innych serwerów nie jest zalecane. Jest to szczególnie problematyczne, jeśli otwarty plik został usunięty z serwera. Serwer może utrzymywać plik otwarty, dopóki nie zostanie ponownie uruchomiony, ale ponowne uruchomienie usunie uchwyt pliku w pamięci po stronie serwera. Wówczas klient nie będzie już mógł otworzyć pliku.

Określenie, które wierzchowce zostały użyte z serwera, jest trudne i zawodne. showmount -aOpcja może pokazać kilka aktywnych wierzchowce, ale nie mogą zgłaszać wszyscy. Zablokowane pliki są łatwiejsze do zidentyfikowania, ale wymagają włączenia blokady i zależy od oprogramowania klienckiego do zablokowania plików.

Możesz użyć lsofna klientach, aby zidentyfikować procesy, które otwierają pliki na wierzchowcach.

Korzystam z opcji hardi intrmount na moich mountach NFS. Ta hardopcja powoduje, że IO jest ponawiane bez końca. Ta intropcja pozwala zabić procesy, które czekają na IFS NFS na zakończenie.

Wypróbuj ten skrypt, który napisałem:

#!/bin/bash
# Purpose:
# Detect Stale File handle and remove it
# Script created: July 29, 2015 by Birgit Ducarroz
# Last modification: --
#

# Detect Stale file handle and write output into a variable and then into a file
mounts=`df 2>&1 | grep 'Stale file handle' |awk '{print ""$2"" }' > NFS_stales.txt`
# Remove : ‘ and ’ characters from the output
sed -r -i 's/://' NFS_stales.txt && sed -r -i 's/‘//' NFS_stales.txt && sed -r -i 's/’//' NFS_stales.txt

# Not used: replace space by a new line
# stales=`cat NFS_stales.txt && sed -r -i ':a;N;$!ba;s/ /\n /g' NFS_stales.txt`

# read NFS_stales.txt output file line by line then unmount stale by stale.
#    IFS='' (or IFS=) prevents leading/trailing whitespace from being trimmed.
#    -r prevents backslash escapes from being interpreted.
#    || [[ -n $line ]] prevents the last line from being ignored if it doesn't end with a \n (since read returns a non-zero exit code when it encounters EOF).

while IFS='' read -r line || [[ -n "$line" ]]; do
    echo "Unmounting due to NFS Stale file handle: $line"
    umount -fl $line
done < "NFS_stales.txt"
#EOF

Na serwerze NFS eksportuj i ponownie eksportuj system plików:

exportfs -u nfs-server: / file_system exportfs nfs-server: / file_system

Na kliencie zamontuj system plików

mount -t nfs nfs-server: / filesystem / mount_point

sprawdź lsof konkretnej ścieżki i zabij odpowiedni pid. Następnie odmontuj partycję i zamontuj ją z powrotem.