![卸载过时的 NFS 绑定](https://linux22.com/image/586512/%E5%8D%B8%E8%BD%BD%E8%BF%87%E6%97%B6%E7%9A%84%20NFS%20%E7%BB%91%E5%AE%9A.png)
我在删除本地挂载的 NFS 文件夹创建的挂载时遇到问题mount -o bind
。假设以下挂载结构:
NFS 挂载目录:
$ mount -o rw,soft,tcp,intr,timeo=10,retrans=2,retry=1 \
10.20.0.1:/srv/source /srv/nfs-source
绑定目录:
$ mount -o bind /srv/nfs-source/sub1 /srv/bind-target/sub1
由此得到了这张挂载地图
$ mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
# ...
10.20.0.1:/srv/source on /srv/nfs-source type nfs (rw,soft,tcp,intr,timeo=10,retrans=2,retry=1,addr=10.20.0.100)
/srv/nfs-source/sub1 on /srv/bind-target/sub1 type none (rw,bind)
如果服务器(10.20.0.1
)宕机(例如ifdown eth0
),句柄就会变得陈旧,这是预料之中的。
我现在可以强制卸载 NFS 挂载
$ umount -f /srv/nfs-source
这需要几秒钟的时间,但没有任何问题。但是,我无法卸载 中的绑定目录/srv/bind-target/sub1
。强制umount
结果如下:
$ umount -f /srv/bind-target/sub1
umount2: Stale NFS file handle
umount: /srv/bind-target/sub1: Stale NFS file handle
umount2: Stale NFS file handle
这是一个踪迹http://pastebin.com/ipvvrVmB
我已尝试预先卸载子目录,查找任何访问 NFS 或绑定挂载中的任意内容的进程(但没有)。
lsof
还抱怨:
$ lsof -n
lsof: WARNING: can't stat() nfs file system /srv/nfs-source
Output information may be incomplete.
lsof: WARNING: can't stat() nfs file system /srv/bind-target/sub1 (deleted)
Output information may be incomplete.
lsof: WARNING: can't stat() nfs file system /srv/bind-target/
Output information may be incomplete.
我已经尝试使用最近的稳定 Linux 内核 3.2.17、3.2.19 和 3.3.8(不能使用 3.4.x,因为需要 grsecurity 补丁,但该补丁尚不受支持 - grsecurity 在上述测试中未打补丁!)。
我的 nfs-utils 是版本 1.2.2(debian 稳定版)。
有人知道我该怎么做吗:
- 用其他方式强制卸载?(任何卑鄙的伎俩都是受欢迎的,此时数据丢失或损坏可以忽略不计)
- 使用其他东西代替
mount -o bind
?(不能使用软链接,因为挂载的目录将在 chroot 中使用;bindfs
通过 FUSE 作为一种选择太慢了)
谢谢,保罗
更新 1
- 使用 2.6.32.59 时,卸载(过时的)子挂载工作正常。这似乎是内核回归错误。
- 上述测试使用的是 NFSv3。使用 NFSv4 进行的额外测试未显示任何变化。
更新 2
- 我们现在已经测试了多个 2.6 和 3.x 内核,现在确信这是在 3.0.x 中引入的。我们将填写错误报告,希望他们能解决这个问题。
答案1
在我的特定设置中,为了让客户端正常工作,对我有用的方法是:
我有一个 autofs 树,其中一个 nfs fs 安装在 /fs/doom 上,另一个安装在 /fs/doom/localvol5 上。服务器重启后,可以访问 /fs/doom 和 /fs/doom/localvol5/sub,但 /fs/doom/localvol5 本身对所有内容都给出了 ESTALE,包括 umount -f、-l、-fl。
为了让客户端无需重启即可运行,我将整个 /fs/doom 层次结构移动到另一棵树:
mkdir /dev/shm/garbage-mount
mount --move /fs/doom /dev/shm/garbage-mount
这移动了整个树,显然只有在 /fs/doom 可访问且是挂载点时才有效。我仍然无法卸载任何这些文件系统,但我能够重新启动 autofs 并获得一个全新且有效的树。
这应该适用于任何具有故障 nfs 子目录的 autofs 树。
希望有所帮助。
答案2
您可以简单地将远程文件系统挂载在 /srv/bind-target/sub1 上。
如果你预计会出现这种程度的不可用性,你还应该为 NFS 指定同步(尽管可能是默认)选项,以降低客户端上出现未写入更改的可能性
答案3
$ umount -l
为我工作,在他们都不工作之前:
$ mount -f ...