5
내 라이브러리 내에서 커다란 (정의 가능한 : 주소 지정 가능한 메모리보다 큰) 파일/블록 장치에 대한 액세스를 투명하고 건전하게 처리하는 방법에 대한 도움말을 찾고 있습니다. 32 비트 아키텍처에서 512GB 크기의 블록 장치가 있다고 가정 해보십시오. 512GB는 우리가 32 비트 아키텍처에서 해결할 수있는 것 이상이며 mmap()을 사용하여 메모리에있는 장치/파일의 일부를 관리하는 것이 내가 피하려고하는 것입니다.대용량 메모리 관리
내가 얻으려고하는 것은 64 비트 숫자/오프셋으로 처리되는 블록을 얻는 것이지만 임의적이지만 크기는 장치마다 다릅니다 (512 바이트, 4K, 8K, 64MB 등) . 호출자는 메모리 주소를 가져와야 만 메모리를 확보하거나 실제 내용을 메모리에로드 할 필요가 없습니다.
다음과 같이 내가 메커니즘에 대해 생각했다 :이 블록이 이미 매핑 된 경우
- 오프셋 (블록 번호)를 복용
void* get_file_address(unit64_t blk_offset)전화 같은 그 검사를하지 따라서에서 읽고 경우 매핑 - (매
get_file_address호 업데이트) 블록 - 메모리가 얼마 남지하고 앞서 언급 구조 ,536을 사용하여 거의 사용되지 블록 언 시작하는 경우에 이용 될 수있는 메모리 관리자에 대한 액세스 횟수를 추적 일부 구조
마지막 요점은 나에게 짜증이났다. 스스로 메모리 관리자를 쓰는 것이 제정신이 아닌 것처럼 보인다. 또한, 나는이 문제가있는 첫 번째 것이 아니라고 확신합니다.
이미 솔루션/라이브러리/codefragment가 이미 있거나 이와 유사한 사례를 관리하는 데 도움이됩니까? Win, Linux, * BSD 또는 OS X에 대한 해결책은 괜찮습니다.
파일의 특정 부분 만 'mmap'하고 블록으로 말하면 왜 액세스하지 않는가? 'mmap'은 오프셋 주소 지정을 지원하므로 파일을 4K 블록 단위로 탐색 할 수 있습니다. – Nobilis
@Nobilis 왜냐하면 내가 mmap을 사용해야한다면 munmap을 사용해야하기 때문이다. 마치 작업이 이미 완료된 것처럼 보이기 때문에 자신을 코딩하지 않으려는 메모리 관리자의 작업이다. 메모리 주소를 얻는다. 장치/파일 + 오프셋을 제공하여 투명하게 – grasbueschel
당신이 512GB의 스왑을 필요로하는 것처럼 보입니다. 나는 놀랍습니다. –