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