☰

vi 在创建新文件之前创建交换文件

tag-icon • tag-icon linux vim nfs
vi 在创建新文件之前创建交换文件

这是一个奇怪的问题。为新文件创建交换文件。所以，我的目录是空的，不存在文件，然后当我vi test.txt收到交换文件消息时。它看起来像vi创建 .swp 文件作为故障转储并向我显示恢复文件消息。

    nfs setting:
    netapp-3240:/vol/vol0/test /testing nfs  rsize=8192,wsize=8192,timeo=14,intr     0 0

    [user@rh-test]cat /etc/redhat-release
    Red Hat Enterprise Linux Server release 5.9 (Tikanga)

    [user@rh-test]ls -la
    total 8
    drwx------ 2 root root 4096 Nov  8 15:35 .
    drwx------ 9 root root 4096 Nov  8 13:59 ..
    /testing 
    
    [user@rh-test]vi test.txt


    E325: ATTENTION
    Found a swap file by the name ".test.txt.swp"
              owned by: rahmed   dated: Fri Nov  8 15:30:06 2013
             [cannot be read]
    While opening file "test.txt"
                 dated: Fri Nov  8 15:29:59 2013

    (1) Another program may be editing the same file.
        If this is the case, be careful not to end up with two
        different instances of the same file when making changes.
        Quit, or continue with caution.

    (2) An edit session for this file crashed.
        If this is the case, use ":recover" or "vim -r test.txt"
        to recover the changes (see ":help recovery").
        If you did this already, delete the swap file ".test.txt.swp"
        to avoid this message.

    Swap file ".test.txt.swp" already exists!
    [O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

    [user@rh-test]ls -la
    total 8
    drwx------ 2 root   root          4096 Nov  8 15:39 .
    drwx------ 9 root   root          4096 Nov  8 13:59 ..
    -rwx------ 1 user   sysadmins    0 Nov  8 15:39 .test.txt.swo
    -rwx------ 1 user   sysadmins    0 Nov  8 15:39 .test.txt.swp

当然，如果我通过 echo 创建文件，则没有交换文件。

    [user@rh-test]echo "this is test file" > test.txt

    /testing
    [user@rh-test]ls -la
    total 8
    drwx------ 2 root   root          4096 Nov  8 15:29 .
    drwx------ 9 root   root          4096 Nov  8 13:59 ..
    -rwx------ 1 user   sysadmins   18 Nov  8 15:29 test.txt

的输出:set dir是directory=.,~/tmp,/var/tmp,/tmp

请注意，这仅发生在该 nfs 挂载上/test。其他本地和 nfs 安装在同一系统上没有此问题。

安装选项：

netapp-3240:/vol/vol0/test on /testing type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr,addr=10.200.23.22)

更改为 nfsvers=2 后，它开始工作

nfsvers=2 或 nfsvers=3 — 指定要使用的 NFS 协议版本。这对于运行多个 NFS 服务器的主机非常有用。如果未指定版本，NFS 将使用内核和 mount 命令支持的最高版本。 NFSv4 不支持此选项，因此不应使用。

netapp-3240-2:/vol/vol1/testing on /test type nfs (rw,rsize=16384,wsize=16384,intr,nfsvers=2,addr=10.200.23.22)

**

解决：

此问题与 NetApp 选项设置不正确有关。为了解决这个问题，我们必须在 NetApp 上设置此选项“options cifs.ntfs_ignore_unix_security_ops on”。**

答案1

电子邮件主题

我发现这个帖子是 2008 年的，似乎过时了，但听起来和你的问题一模一样。这似乎是 NetApp 特有的事情。我注意到，在您的输出中，服务器被命名netapp-3240为 NetApp 设备。

该线程的标题是：奇怪的行为，NTFS qtree 上的 Linux 和 NFS。具体来说，其中提到了您正在经历的相同症状。

问题概要

摘抄

我目前正在评估的 FAS3040 文件管理器出现一些奇怪的行为。我有一个由 NFS 和 CIFS 导出的 NTFS 样式 qtree。 Debian Linux 客户端会看到与 open() 和 stat64() 系统调用相关的奇怪行为。简而言之，“vim”的 strace 输出捕获了它：

   uname({sys="Linux", node="acheron", ...}) = 0 
    stat64("ffff", 0xbfb4d030) = -1 ENOENT (No such file or directory) 
    stat64("ffff", 0xbfb4d0b0) = -1 ENOENT (No such file or directory) 
    access("ffff", W_OK) = -1 ENOENT (No such file or directory) 
    open("ffff", O_RDONLY) = -1 ENOENT (No such file or directory) 
    readlink("ffff", 0xbfb4c7cc, 1023) = -1 ENOENT (No such file or directory) 
    open(".ffff.swp", O_RDONLY) = -1 ENOENT (No such file or directory) 
    open(".ffff.swp", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
    stat64(".ffff.swp", {st_mode=S_IFREG|0777, st_size=0, ...}) = 0

请注意，open(O_RDWR...) 调用失败并显示 EACCES；但以下 stat64() 调用成功。尽管报告 open() 调用失败，但文件 ffff.swp 仍在磁盘上创建。

使用“vim”编辑文件时会出现此行为，并导致出现有关交换文件存在的错误消息（因为交换文件正在创建，即使 open() 返回值暗示它不存在）。

在 Tru64 NFS 客户端上尝试相同的“vim”命令，可以看到正确的行为：open(O_RDWR...) 成功并返回文件句柄。

nfsver=2

有这个建议解决了这个问题。您可以尝试它，只是为了确认您遇到了该线程正在解决的相同问题。

摘抄

但在收到你的电子邮件后，我尝试了 vers=2，问题就消失了（TCP 和 UDP 都适用），这确实很有趣。尽管这里的文件和文件系统非常大，但 NFSv3 仍然非常理想。

对你的出口做这样的事情：

rw,intr,tcp,nfsvers=2,rsize=16384,wsize=16384,addr=192.168.1.1

cifs.ntfs_ignore_... 选项

线程中还有一件事要尝试：

在文件管理器上将选项 cifs.ntfs_ignore_unix_security_ops 设置为 on 可能会起作用。

还有什么？

除了这些事情之外，还有其他一些事情需要尝试，但我无法确认，因为我无法访问 NetApp 文件管理器来进行尝试。 NetApp 网站上还有一些 URL 供您探索，但我也无法确认这些内容。

无论如何，我强烈建议您浏览一下这个线程，因为它似乎是您奇怪的vim说法它有一个 .swp 文件而实际上没有的主要候选者。

答案2

这是一个很好的话题，谢谢大家。

我想我应该补充一下，因为我们在非 NetApp 存储提供商上看到了完全相同的问题。

我们正在运行带有 UEK 5 的 Oracle Enterprise Linux 7，每次尝试在 EMC 数据域上创建文件时，我们都会收到有关我们动态创建的文件的 vi 的 swp 文件预先存在的错误。

事实证明，这似乎是 UEK 5 内核中的一个错误。我们将服务器从 UEK 5 切换到 UEK 4，一切按预期工作。我们可能会就该问题向 Oracle 开具票证。

相关内容