☰

sshfs를 통해 파일 수정

tag-icon • tag-icon ssh filesystems synchronization sshfs touch
sshfs를 통해 파일 수정

머신 A의 파일 시스템은 es에서 실행되는 프로세스를 B통해 신호를 전달하며 , es가 마운트한 파일 시스템의 파일에 의해 시작됩니다. 그런 다음 신호(파일)가 제거됩니다. 이는 파일이 처음 생성/파기될 때( / ) 안정적으로 작동합니다.sshfsBAssh touchAAtouchrm

그러나 두 번째 프로세스(다시 B,slave 에서 실행 중 A)가 정확히 동일한 파일을 터치하려고 하면 다음 오류가 발생합니다.산발적으로던지기:

`touch: cannot touch '/path/to/file': No such file or directory`.

touch오류가 발생한 후 수동으로 시도하면 성공한다는 사실로 판단하면 경로가 유효합니다 . 언급한 대로 오류는 산발적이지만(디버깅 시도를 복잡하게 함) 이미 생성/삭제 루프를 거친 후 파일을 터치할 때만 발생합니다.

간헐적으로 오류( touch, rm, touch)가 발생하는 작업은 시간적으로 분리되어 있기 때문에 동시 접속이 원인이 될 가능성은 거의 없습니다(즉, 첫 번째 터치로 생성된 파일이 삭제될 때까지 두 번째 터치가 발생하지 않습니다). 원인은 파일을 삭제한 후 sync호출되는 파일 시스템 버퍼링에서 비롯된 것일 수 있다고 생각했지만 A소용이 없었습니다. 호출이 영향을 미칠지 는 모르겠지만 sync파일을 터치하기 직전에 호출하는 것도 도움이 되지 않습니다( on 버전에는 명시적인 파일 시스템 사양에 대한 옵션이 부족합니다. 실행 중인 프로세스에서 via before ing을 호출해 보았습니다. 하지만 동기화 오버에서는 작동하지 않습니다. -ssh 호출 후 해당 명령문을 포함한 나머지 행이 실행되지 않기 때문에 프로세스가 오류 없이 종료되는 것 같습니다. 아마도 프로세스에서 서버에서 클라이언트로 돌아갈 수 없기 때문일 것입니다. 클라이언트에서 서버로 시작됨)BBsyncAsyncB-fsyncABssh user@A synctouchtouchsshssh

이 파일 시스템 관련 오류의 원인을 어떻게 확인할 수 있습니까?

답변1

옵션을 사용하여 sshfs를 실행하면 무슨 일이 일어나고 있는지 조사할 수 있습니다 -o debug. 명령으로 수행되는 기본 파일 시스템 작업에 대한 광범위한 정보를 인쇄합니다 touch test. 예제 작업은 다음과 같습니다.

unique: 209, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 10641
LOOKUP /test
getattr /test
   NODEID: 44
   unique: 209, success, outsize: 144

관련 부분은 getattr통화가 성공적으로 완료되고 종료되었다는 것입니다. 존재하지 않는 파일을 성공적으로 터치하면 다음과 같은 작업이 표시됩니다(세부 정보 제거).

getattr /test
   unique: 190, error: -2 (No such file or directory), outsize: 16
create flags: 0x8841 /test 0100644 umask=0022
fgetattr[140469187119648] /test
flush[140469187119648]
utime /test 1507647885 1507647885
getattr /test
flush[140469187119648]
release[140469187119648] flags: 0x8801

이 파일에 대한 getattr 테스트가 실패했음을 확인했습니다. 이는 존재하지 않기 때문에 정상적인 현상이므로 계속해서 파일을 생성합니다.

이제 파일이 서버에서 삭제되고 클라이언트에서 다시 터치하면 다른 순서가 표시됩니다.

getattr /test
   unique: 215, success, outsize: 144
open flags: 0x8801 /test
   unique: 216, error: -2 (No such file or directory), outsize: 16

이제 getattr은 파일이 여전히 존재한다고 말하므로 파일 touch처리를 계속 open()하지만 이로 인해 파일이 전혀 존재하지 않는다는 오류 메시지가 나타납니다.

따라서 기존 파일을 캐싱하는 클라이언트가 원격 변경 사항을 따라잡기에는 너무 느린 문제인 것 같습니다. 가장 간단한 대답은 호출 getattr(예: stat()시스템 호출) 시간 초과를 짧게 설정하여 리모컨을 설치하는 것입니다 . 이것은 당신에게 도움이 될 것입니다

sshfs -o cache_stat_timeout=0 ...

관련 정보