NFS로 inotify

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