동일한 ext4 디스크를 두 개의 호스트 (하나만 읽기 전용)에서 마운트 할 수 있습니까?


17

두 개의 다른 서버 (iSCSI vloume)에서 ext4 파일 시스템으로 동일한 디스크를 마운트하면 디스크의 데이터가 손상 될 수 있음을 알고 있습니다. 내 질문은 서버 중 하나가 디스크를 읽기 전용으로 마운트하고 다른 서버는 읽기 / 쓰기로 마운트하면 차이가 있습니까?

OCFS2 또는 이와 유사한 것을 사용할 수 있으며 NFS로 디스크를 내보내 다른 서버에 액세스 할 수 있다는 것을 알고 있지만 제안한 설정이 작동하는지 알고 싶습니다.


1
둘 다 읽기 전용으로 마운트 된 경우에만 작동 할 수 있습니다. 한 쪽이 읽기-쓰기를 마운트하자마자 다른 쪽 (마운트 된 읽기 전용)은 다른 쪽 (마운트 된 읽기-쓰기)에 의한 변경을 기대하지 않으므로 손상된 데이터를 읽습니다. 필요한 것은 클러스터 인식 파일 시스템이거나 네트워크 파일 시스템을 다른 파일 시스템에 노출시키는 단일 서버입니다.
frostschutz

@frostschutz 예, ext4의 ro-mount가 실제 디스크에 기록하기 때문에 ro가 모두 작동하지만 트릭은 없습니다.
Ned64

여기서 유스 케이스를 공유하겠습니다. 실제 서버와 가상 서버는 디스크 통과와 실제 디스크를 공유합니다. 가상 서버가 디스크를 rw로 마운트하고 있습니다. 디스크에서 많은 양의 데이터를 복사하고 싶지만 네트워크 속도가 너무 느립니다. 호스트 OS에서 물리적 디스크를 ro로 마운트하고 데이터를 외부 USB 드라이브에 복사 할 수 있다면 좋을 것입니다. 호스트 서버에는 USB 컨트롤러가 하나만 있으므로 PCI 패스 스루는 옵션이 아닙니다.
Zhuoyun Wei

답변:


26

아니요. 캐싱으로 인해 읽기 전용 클라이언트에 일관된 결과를 제공하지 않습니다. 확실히 설계된 것은 아닙니다. IO 오류가 애플리케이션으로 리턴 될 것으로 예상 할 수 있습니다. 코드에는 여전히 많은 수의 감독이있을 수 있는데, 이로 인해 커널 충돌이 발생하거나 프로세스가 사용하는 메모리가 손상 될 수 있습니다.

그러나 가장 중요한 것은 ext4가 읽기 전용 마운트에서도 저널을 재생한다는 것입니다. 따라서 읽기 전용 마운트는 여전히 기본 블록 장치에 씁니다. 마운트가 모두 읽기 전용 이더라도 안전하지 않습니다 . :).


5
당신이 말했듯이, 읽기 전용 마운트는 파일 시스템이 손상되지 않는다고 보장하지 않습니다. 위험을 감수하지 않고 "교육적인"목적을 계속 시도하려면 장치를 읽기 전용으로 설정해야 합니다blockdev --setro /dev/sda1 .
Totor

ext4 마운트에 대한 흥미로운 정보입니다. ext2 읽기 전용 마운트를 강제 실행 하여이 문제를 피할 수 있다고 생각합니까?
Bananguin

1
: 나는 나를 VM에서 읽기 전용 블록 장치를 장착 할이 코드 조각을 발견 sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/...을
isaaclw

0

이것은 데이터 손상을 피할 것이지만 아마도 당신이 원하는 것이 아닐 것입니다. 다른 노드에서 볼륨을 읽기 전용으로 마운트하는 데 아무런 문제가 없었습니다. 일반적으로 "예기치 않은 프리 아이 노드를 던지는 ro 노드에서 어떤 것이 일치하지 않더라도 / var / log / messages에 e2fsck"등을 실행하십시오. 중요하지 않은 파일 시스템 ( "/ opt / mySpecialmount")에 대해 예상치 못한 일이 발생하는 경우 일반적으로 Linux는 볼륨을 읽기 전용으로 마운트합니다 (여기서 이미 있습니다). 캐싱의 효과에 대해 걱정이된다면 drop_caches / vfs_cache_pressure 체제를 시도해 볼 수 있습니다.

저널 재생을 피하려면 마운트 인수에 "noload"를 추가하고 errors = remount-ro와 함께 수행하십시오 (주의 측면에서 오류가 발생 함).

즉, 읽기 전용으로 마운트해도 괜찮다면 다른 노드에 대한 참조 일 가능성이 큽니다.이 경우 NFS 또는 smbfs가 문제를 해결하고 ext3 /보다 약간 더 동시성을 위해 설계되었습니다 4입니다. 성능이 필요한 경우 클러스터 된 파일 시스템을 살펴볼 수 있습니다 (관리 오버 헤드가 조금 더 많지만 성능이 실제로 필요한 경우가 있습니다).


1
" 이것은 데이터 손상을 피할 것입니다 ": 그렇지 않을 수도 있습니다. sourcejedi의 답변과 내 의견을 참조하십시오 .
Totor

1
"저널 재생을 중단하면 파일 시스템에 불일치가 포함되어 여러 가지 문제가 발생할 수 있습니다."- man mount. 파일에서 일치하지 않는 데이터를 감지 및 / 또는 견딜 수있는 응용 프로그램이 있다고 생각할 수 있지만 지금까지 이러한 경고는 언급하지 않았습니다. :)
sourcejedi

@sourcejedi 그들은 사람들에게 저널을 효과적으로 부수어 놓을 위험을 알려 주려고 노력하고 있다고 말합니다. 다른 노드가 다른 노드에 대한 저널 작업을 수행 할 것이라는 가정하에 이중 작업을 피하려고합니다. 우리는 개발 서버 중 하나 (내가 선택하지 않았고 NFS를했을 것입니다) 에서이 작업을 수행했으며 아무런 문제없이 1 년 가까이 drop_caches없이 마운트했습니다. 우리는 비 스토리 FS 캐시 항목이 오래된 데이터를 렌더링 할 수 있다고 언급했지만 궁극적으로 이것이 가능한지 결정하는 것은 관리자의 책임입니다.
Bratchley

위의 의견에서 모든 잘못을 열거하려고하지는 않습니다. 그러나 하나의 데이터 포인트로서 VFS 캐시의 오래된 파일 데이터가 아닙니다. ext4는 파일 시스템 내부 데이터 구조 ( "메타 데이터")의 캐시도 갖습니다. 삭제 된 파일에서 데이터를 읽은 후 새 파일로 덮어 쓸 수 있습니다. 그것은 가끔 발생하는 경우에도 미리 알고 싶은 종류의 경고입니다.
sourcejedi

1
귀하의 의견을 되돌아 보면 메모리에서 블록 장치 I / O를 캐싱하는 블록 수준 캐싱을 참조하려고한다고 생각합니다. 어떤 경우에, 해당 캐싱되지 것은 메타 자체, 그것의 캐시 발생 OF 메타 자체. 또한 파일 시스템 드라이버 외부에 존재하므로 ext4 / btrfs / etc는 관리하지 않습니다.
Bratchley
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.