64MB와 같이 특히 큰 파일이 있는 경우 파일의 물리적 하드 드라이브 위치를 찾은 다음 특정 오프셋의 바이트를 파일로 읽을 수 있는지 궁금합니다.
파일 시작 부분에서 60MB 오프셋 100바이트에 관심이 있다고 가정해 보겠습니다. 일부 애플리케이션 수준의 eek() 함수를 사용하는 경우 파일 시작 부분부터 파일 끝까지 수백 번의 디스크 검색을 수행해야 하는 비효율성을 원하지 않습니다.
해결책이 있나요?
매우 감사합니다!
답변1
seek()
어떻게 행동해야 하는지에 대해 오해가 있는 것 같습니다 . 중간 바이트를 읽지 않고 이 오프셋의 데이터가 최대한 효율적으로 저장되는 위치를 찾습니다. 블록 인덱스를 탐색하기 위해 여러 번의 조회(아마도 수백 번은 아님)가 있을 것입니다.
당신이 할 수 없는 일은 파일이 열릴 때부터 다음 번에 열릴 때까지의 블록 인덱스 순회를 저장하는 것입니다. 운영 체제는 파일이 마지막으로 열린 이후 수정되거나 재배치되지 않았음을 기억해야 하며, 이는 매우 작은 잠재적 이득을 위해 많은 데이터를 기억해야 합니다.
파일의 내용은 일반적으로 인접한 디스크 위치에 있지 않습니다. 파일은 조각화되는 경향이 있습니다. 파일 시스템은 일반적으로 조각화를 줄이려고 노력하지만 일반적으로 이것이 보장되지는 않습니다.
답변2
다시 읽어보니, 근본적인 질문에 대답하지 못한 것 같습니다.
애플리케이션(실제로는 커널) 수준에서 "조회"를 사용한다고 해서 반드시 디스크에서 "조회" 비용이 드는 것은 아닙니다. 단지 파일 핸들과 관련된 오프셋을 업데이트하는 것뿐입니다.
커널에 읽기 또는 쓰기를 요청하면 해당 오프셋을 디스크 오프셋으로 변환합니다. 이를 알아내기 위해 블록을 읽어야 할 수도 있지만 가장 좋은 경우는 직접 방문과 마찬가지로 단일 조회 비용입니다.
확실히 이렇게 하는 것이 가능합니다. 결국 이것이 바로 파일 시스템 드라이버가 하는 일이므로 다른 사람들도 그렇게 할 수 있어야 합니다. 필요한 것은 원시 디스크에 대한 액세스뿐입니다.
거기 예 ~의 예사람들은 기존 파일 시스템 형식에 대해 이 작업을 수행합니다. 필요한 경우 이 작업을 수동으로 수행할 수도 있습니다.
파일 시스템이 활발하게 사용되는 경우 디스크에 있는 내용이 눈에 보이지 않는 방식으로 변경되기 때문에 이를 더욱 어렵게 만드는 몇 가지 기술적인 문제에 직면하게 되지만 여전히 가능합니다.
커널에 직접 물어볼 수도 있습니다.xfs_bmap도구는 이를 수행할 수 있으며 최소한 일부 파일 시스템은 동일한 인터페이스를 구현하므로 직접 요청할 수 있습니다.
위치를 계산하는 데는 커널과 동일한 검색 횟수가 필요하므로 실제로 저장할 가능성은 거의 없습니다.아무것이 작업을 수행.
답변3
난 그렇게 생각하지 않아.
파일을 열면 시작(읽기/쓰기) 또는 끝(추가)에 있게 됩니다. "업데이트 모드"에서도 단순히 파일 중간의 특정 위치에 도달하지 않습니다.
나는 당신이 할 수 있는 최선의 방법은 이미 벗어난 것이라고 생각합니다. 처음부터 오프셋을 계산할 수 있다면 해당 위치를 직접 찾아 데이터를 읽을 수 있습니다. 그 사이에 과도한 읽기가 포함될 것이라고는 생각하지 않습니다. 파일을 연 후 다음 읽기는 계산된 오프셋에 있어야 합니다.