development

NFS로 inotify

big-blog 2020. 12. 25. 22:42
반응형

NFS로 inotify


최근에 inotify를 사용하여 특정 디렉터리에 생성 된 파일을 감시하는 보관 용 시스템을 만들었습니다. 내가보고있는 디렉토리는 NFS 서버에서 마운트되고 inotify는 내가 예상했던 것과 다르게 작동합니다. inotify 스크립트가 시스템 A에서 실행되고 / some / nfs / dir / also / visible / to / B를보고있는 다음 시나리오를 고려하십시오.

-컴퓨터 A를 사용하여 / some / nfs / dir / also / visible / to / B에 파일을 만들면 스크립트가 예상대로 작동합니다. 시스템 B를 사용하여 동일한 작업을 수행하면 디렉토리에 드롭 된 새 파일에 대한 알림이 스크립트에 표시되지 않습니다.
-스크립트가 NFS 서버에서 실행되면 시스템 A와 시스템 B에서 파일이 생성 될 때 알림을받습니다.

inotofy에 액세스하는 데 사용중인 패키지의 버그에있는 버그입니까, 아니면 예상되는 동작입니까?


inotify가 작동하려면 커널의 지원이 필요합니다. 응용 프로그램이 디렉토리를 추적 할 때 이러한 변경 사항이 발생하면이를 알리도록 커널에 요청합니다. 변경이 발생하면 해당 변경 사항을 디스크에 기록하는 것 외에도 커널은 감시 프로세스에 알립니다.

원격 NFS 시스템에서 변경 사항은 커널에 표시되지 않습니다. 완전히 원격으로 발생합니다. NFS는 inotify보다 이전 버전이며 NFS 또는 이와 동등한 네트워크 수준의 지원이 없습니다.

이 문제를 해결하려면 원격 시스템에 대한 요청을 inotify하고 원격 클라이언트에 데이터를 전달하는 스토리지 서버에서 서비스를 실행할 수 있습니다 (커널은 항상 파일 시스템에 대한 변경 사항을 확인하므로).

편집 : NFS 가 inotify에 대한 지원 부족으로 인해 비난 받아야한다는 것이 이상하게 보입니다 .

네트워크 파일 시스템 (NFS)는 원래 개발 한 분산 파일 시스템 프로토콜입니다 1984 년 썬 마이크로 시스템즈 , 기사 위키 백과

하나:

Inotify (inode 알림)는 파일 시스템의 변경 사항을 알리기 위해 파일 시스템을 확장하는 역할을 하는 Linux 커널 하위 시스템입니다. [...] 릴리스 2.6.13 ( 2005 년 6 월 18 일 ) [...] 부터 메인 라인 Linux 커널에 포함되었습니다 . 위키 백과 기사

휴대용 네트워크 프로토콜 / 애플리케이션이 다른 운영 체제 용으로 개발 된 특정 커널 기능을 지원할 것으로 기대하기는 어렵고 20 년 이상 후에 나타납니다 . 확장 기능 포함되어 있어도 다른 운영 체제에서는 사용할 수 없거나 유용하지 않습니다.

* 모든 경우에 내 강조


이것에 대한 또 다른 문제; 네트워크를 전혀 사용하지 않고 inotify 지원이 좋은 로컬 파일 시스템 인 ext3 (에 마운트 된 것으로 가정 /mnt/foo)을 사용한다고 가정 해 보겠습니다 . 그러나 실제 디스크 대신 파일 시스템은 루프백 장치에서 마운트됩니다. 기본 파일은 vfs의 다른 위치에서 액세스 할 수 있습니다 (예 :) /var/images/foo.img.

이제 마운트 된 ext3 파일 시스템을 수정해서는 안됩니다.하지만 메타 데이터 대신 파일 내용을 변경하는 경우에는 그렇게하는 것이 합리적으로 안전합니다.

따라서 영리한 사용자 /var/images/foo.img가 16 진 편집기에서 파일 시스템 이미지 ( )를 수정하여 파일 의 내용을 다른 데이터로 바꾸는 동시에 inotify 감시자가 마운트 된 파일 시스템에서 동일한 파일을 관찰 한다고 가정합니다 .

이런 종류의 변화를 감시 과정에 항상 알리기 위해 inotify를 준비 할 수있는 합리적인 방법은 없습니다. ext3를 알리고 변경 사항을 존중하기 위해 취할 수있는 회전이있을 수 있지만, xfs drtiver에는 적용되지 않을 것입니다.

그럴 수도 없습니다. 당신은 바람을 피우고 있습니다!. inotify는 감시중인 실제 마운트 지점에서 vfs를 통해 발생한 변경 사항 만 알려줄 수 있습니다. 기본 데이터의 변경으로 인해 해당 VFS 외부에서 변경이 발생한 경우 inotify는 해당 문제를 해결하도록 설계되지 않았습니다.

네트워크 알림을 위해 메시지 대기열 사용을 고려해 보셨습니까?


파일 수정을 모니터링하기 위해 감독자 데몬을 사용 하는 SGI FAM찾았습니다 . NFS를 지원하며 위키에서 몇 가지 설명을 볼 수 있습니다.


Docker의 바인드 마운트가 호스트 디렉토리에서 파일 변경 사항을 감지하지 못하는 이유 (앱의 핫 리로딩)에 대한 답을 찾기 위해이 질문을 접한 사람에게는 호스트와 컨테이너 간의 파일 변경 전파가 그렇지 않기 때문입니다. 컨테이너 커널에 전달됩니다.

컨테이너 자체의 변경 사항 만 커널에 전달됩니다. 이에 대한 해결책은 fsnotify를 사용하는 대신 라이브 리로드 유틸리티를 "폴링 모드"로 설정하는 것입니다.


SingleNegationElimination의 설명에 동의하며 커널에 경고를 보내므로 iSCSI 대상이 작동 할 것이라고 추가하고 싶습니다.

따라서 "실제"파일 시스템 (즉, 시스템에 비해)에있는 항목은 Inotify가 경고하도록 트리거합니다. Rsync'ing과 마찬가지로 마운트 된 파티션에 무언가를 net-catting합니다.

inotify를 통해 알림을 받아야하는 경우 (또는 inotify를 사용해야하는 경우) 파일 시스템에 대해 rsync -avz에 cron을 만들 수 있습니다. 물론 단점은 실제 시스템 HDD 공간을 사용하고 있다는 것입니다.


나는 두 번째 @SingleNegationElimination.

또한 notify-forwarder를 시도 할 수 있습니다 .

  • 머신 A는 로컬 inotify 이벤트를 감시 한 다음 UDP를 통해 머신 B로 전달합니다.
  • 시스템 B는 이벤트를 재생하지 않지만 (할 수 없습니까?) 변경된 파일에 대해 ATTRIB 이벤트를 발생시킵니다.

vagrant를 사용 하는 경우 vagrant-notify-forwarder를 사용하십시오 .

참조 URL : https://stackoverflow.com/questions/4231243/inotify-with-nfs

반응형