☰

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

물론 에코를 통해 파일을 생성하면 스왑 파일이 없습니다.

    [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-3240NetApp 장치로 지정되어 있는 것으로 나타났습니다.

스레드 제목은 다음과 같습니다.Linux 및 NFS에서 NTFS qtree의 이상한 동작. 특히, 귀하가 겪고 있는 동일한 증상을 언급하고 있습니다.

문제 요약

발췌

현재 평가 중인 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이 몇 개 더 있지만 그 중 하나도 확인할 수 없습니다.

어쨌든, 이 스레드를 살펴보는 것이 좋습니다. .swp 파일이 없는데도 .swp 파일이 있다는 당신의 기괴한 주장에 vim대한 주요 후보 인 것 같기 때문입니다.

답변2

이것은 훌륭한 주제입니다. 모두 감사합니다.

NetApp 이외의 스토리지 제공업체에서도 동일한 문제가 발생하므로 이 점을 추가해야 할 것 같습니다.

우리는 UEK 5와 함께 Oracle Enterprise Linux 7을 실행하고 있으며 EMC 데이터 도메인에 파일을 생성하려고 할 때마다 동적으로 생성하는 파일에 대한 vi의 swp 파일에 대한 기존 오류가 발생합니다.

결과적으로 이는 UEK 5 커널의 버그인 것으로 보입니다. 서버를 UEK 5에서 UEK 4로 전환했는데 모든 것이 예상대로 작동했습니다. 이 문제와 관련하여 Oracle에 티켓을 열 수 있습니다.

관련 정보