일반적으로 블록 장치 드라이버는 장치의 정확한 크기를 보고하며 "사용 가능한" 모든 블록이 실제로 사용될 수 있습니다. 따라서 파일 시스템은 해당 장치에 쓸 수 있는 양을 미리 알고 있습니다. 그러나 장비를 사용 하거나 장비를
사용할 때와 같은 일부 특수한 경우에는 이 진술이 잘못되었습니다. 이러한 블록 장치는 기본 저장소(상위 FS가 알지 못하는)가 가득 찬 경우 언제든지 오류를 반환할 수 있습니다. 그래서 내 질문은 이 상황에서 무슨 일이 일어나는가 하는 것입니다. EXT4 파일 시스템이 모드(기본값) 로 마운트되어 있고 많은 쓰기를 수행하고 있습니다. 디스크 캐시(더티 메모리)도 작동하게 되는데, 사용자가 명령을 실행하면 쓸 데이터가 많아지게 됩니다. 그러나 갑자기 해당 EXT4 파일 시스템의 기본 블록 장치는 "남은 공간이 없다"는 이유로 모든 쓰기를 거부하기 시작합니다. 파일 시스템의 동작은 무엇입니까? 오류를 인쇄하고 모든 쓰기를 중단하고 데이터 손실을 일으킬 수 있는 모드 로 전환됩니까 ? 그렇지 않은 경우 공간을 기다렸다가 주기적으로 쓰기를 다시 시도하고 새 쓰기를 거부합니까? 이 경우 다른 프로세스가 대량의 RAM을 할당하려고 하면 거대한 디스크 캐시는 어떻게 되나요? (리눅스에서는 더티 메모리가 무료로 간주됩니다. 그렇죠?) 최악의 시나리오를 고려하면, 오류가 발생할 때 디스크 캐시가 RAM의 대부분을 차지하면 (관리자가 RAM을 너무 높게 설정했기 때문에) 커널이 충돌하거나 잠기게 될까요? 아니면 메모리를 할당하려는 모든 프로세스를 대기/중지하게 만들까요? 마지막으로, 서로 다른 파일 시스템이 다르게 동작합니까? 미리 감사드립니다.dm-thindm-vdoENOSPCr/wasyncsyncr/oENOSPCvm.dirty_ratio
답변1
블록 장치가 사용 가능한 데이터 용량을 과도하게 사용하거나(예: 씬 프로비저닝 사용 시) 다른 이유로 더 많은 쓰기를 허용할 수 없는 경우(예: 스냅샷 가득 참) 쓰기에 메시지를 보내야 합니다. 이 경우 ENOSPC는 의미가 없으므로 일반적으로 선택된 오류는 EIO(오류 입력/출력)입니다.
업데이트: LVM에는 실제로 구성 가능한 동작이 있습니다.씬 프로비저닝 LV용:
--errorwhenfull n(기본값): OP가 고려하는 대로 최대 (구성 가능) 60초 동안 차단한 다음 오류를 발생시킵니다. 이 60초 이내에 자동 조치가 수행되지 않으면 결과는 즉각적인 오류와 동일합니다.또한 시간 초과를 완전히 비활성화하는 경우 다음 사항에 유의하세요.
시간 초과를 비활성화하면 시스템 리소스 고갈, 메모리 고갈, 작업 중단 및 교착 상태가 발생할 수 있습니다. (시간 초과는 시스템의 모든 가상 풀에 적용됩니다.)
--errorwhenfull y: 오류 즉시 반환
"사용자"가 파일 시스템인 경우 실제 미디어 오류로 인해 발생한 것처럼 I/O 오류에 반응합니다. 이는 마운트 옵션에 따라 달라질 수 있습니다(예:외부 4가능한 옵션은 errors={continue|remount-ro|panic})입니다. 긴급하지 않은 옵션 중 하나를 선택하면 캐시에 있는 더티 데이터가 어떻게 되는지 잘 모르겠습니다. 캐시에 남아 있거나 손실될 것이라고 상상할 수 있지만 어쨌든 손실될 것이라고 가정해야 합니다.
이는 심각한 결과이므로 이러한 디스크 공간을 적극적으로 모니터링하고 임계값에 도달하면 과도하게 사용되는 공간이 가득 차지 않도록 데이터를 해제하거나 실제 공간을 더 추가해야 합니다. 스냅샷, 특히 시간이 지남에 따라 더 많은 공간을 사용하는 씬 프로비저닝되지 않은 스냅샷의 경우에도 마찬가지입니다. 더 이상 필요하지 않으면 삭제해야 합니다. 긴급 상황이 발생할 경우 씬 프로비저닝된 공간을 자동으로 늘리는 옵션도 있습니다(씬 프로비저닝된 계층에 공간을 제공하는 계층이 여전히 더 많은 공간을 제공할 수 있는 경우).
추가 참조:
답변2
파일 시스템(및 설치 옵션도 가능) 및 기본 스토리지에 따라 다릅니다.
대부분의 경우 공간 과다 할당으로 인해 블록 장치에 쓸 수 없으면 IO 오류로 파일 시스템 드라이버에 즉시 전파됩니다. LVM에는 이 작업을 지연할 수 있는 옵션이 있지만(주로 자동 크기 조정 기능이 시작될 시간을 제공하기 위해) 기본적으로 비활성화되어 있습니다. QEMU에는 희소 디스크 이미지로 이 동작을 제어할 수 있는 옵션이 있지만 기본적으로 게스트 운영 체제에 오류를 전파합니다(오류를 무시하거나 가상 머신을 일시 중지하도록 구성할 수도 있음). 그러나 대부분의 다른 것들은 파일 시스템 드라이버에 즉시 오류를 발생시킵니다.
여기서 일어나는 일은 파일 시스템에 따라 다릅니다. 거의 항상 ENOSPC가 아닌 EIO이지만 거의 모든 경우 오류가 사용자 공간으로 전파됩니다(ENOSPC는 파일 시스템에 공간이 부족하다는 의미이지만 여기서는 기술적으로 문제가 아니며 일반적으로 파일 시스템도 확인할 수 없습니다). IO 오류는 하위 계층에서 발생하므로 일반적으로 하위 계층의 공간 부족으로 인한 것인지 알 수 없습니다. 기본적으로 ext4는 다른 작업을 수행하지 않지만 마운트 옵션(및 에서 설정한 내용 tune2fs)에 따라 읽기 전용으로 다시 마운트하거나 커널 패닉을 유발할 수 있습니다. BTRFS는 읽기 전용으로 다시 마운트되며 일부 다중 장치 설정에서는 성능 저하 모드로 전환될 수도 있습니다. 다른 파일 시스템에 대해서는 잘 모르겠습니다(비록 이 경우에는 XFS가 읽기 전용으로 다시 마운트될 것으로 예상하지만).