5
"ecryptfs"는 직접 I/O를 지원합니까? 일반적으로 사용자 지원 직접 I/O에서 제공하는 버퍼를 수정하는 "스택 가능"파일 시스템은 어떻게 될 수 있습니까?ecryptfs 및 유사한 스택 가능 파일 시스템에서 직접 IO 사용
A
답변
3
ecryptfs는 직접 I/O를 지원하지 않습니다.
ecryptfs address_space_operations에는 direct_IO() 콜백 구현이 없습니다.
+0
데이터를 수정하는 스택 가능 파일 시스템에이 기능을 어떻게 추가 할 수 있는지 알고 있으면 좋을 것입니다. 특히 비동기 IO가 Direct I/O로 수행되는 경우. 어떻게 우리는 사용자 버퍼의 일관성을 보장 할 수 있습니까? * 직접 I/O의 의미를 유지할 수 있습니까? – ghostkadost
0
필자는이 정도를 들여다 보지 않았지만 개인적으로는 파일 시스템 드라이버에 decorator pattern을 사용하여 ecryptfs가 실제 장치 드라이버 위에 위치하도록했습니다. 그런 다음 호출이 이루어지면 ecryptfs 코드로 이동 한 다음 ecryptfs가 장치 드라이버를 호출하고 쓰기를 수행합니다.
직접 I/O는 "데이터가 버퍼 캐시로 들어오지 않으며 버퍼 캐시로 들어 가지 않습니다."를 의미합니다. 따라서 특정 파일 시스템이이를 지원할 수 없어야하는 이유는 없습니다. 물론 암호화 된 파일 시스템의 경우 섹터를 읽을 때마다 반복해서 암호를 해독해야합니다 ... – Damon
여기 쓰기 작업이 어떻게 구현되는지가 중요합니다. 복사가 불가능할 경우 사용자 버퍼의 데이터를 암호화하고 쓰기 작업을 수행 한 다음 데이터를 다시 해독해야하므로 사용자 버퍼를 수정하지 않아야합니다. 비동기 I/O가 그림에 던져지면이 작업이 어려워야합니다. – ghostkadost
'O_DIRECT'는 비동기 연산을 제공하지 않거나 그렇지 않으면 엄청나게 많은 것을 약속합니다. _really_ 약속은 (원래의 견적) "캐시 효과를 최소화하려고"하는 것입니다 버퍼 캐시를 통해 이동하지 않음으로써. 그것은 어떤 사본도 만들어지지 않는다고 보장하지 않습니다. 피할 수있는 사본은 피합니다. 그리고 종종 사람들이 생각하는 것의 반대 (성능 저하)를합니다. 분명히 섹터를 암호화하는 경우 디스크 컨트롤러에 HW 암호화가 없으면 복사본을 만들어야하지만 그렇게 할 수는 없습니다. 그래도 나중에 버퍼 캐시에 들어 가지 않습니다. – Damon