순차파일 또는 인덱스된 파일을 만들 때 최대한 디스크 접근을 줄이는 방법?

일단 데이터파일들을 분리하는 방안을 검토해보세요..
그리고.. 각 데이터파일들을. 분산해시테이블처럼 관리하시고 개별파일(파티션)들에 개별 인덱스파일을 두시는게 어떠실지.

좀 천진난만한 생각일 지 몰라도... 파일시스템을 쓰지 않으면 어떨까요 ?

데이타를 그냥 /dev/sdb 에 보관하는 식이죠. (O_DIRECT 나 /dev/raw/ 사용하고.)
단, 파일 시스템의 기능이 필요하다면 어플리케이션 자체적으로 해야합니다.
cache, buffer, lookup table 같은 것 말입니다.

주로 DB 서버 응용이나 media player 응용에서 각광받습니다만,
현재 고민하고 계시는 그 응용은 이것들보다 더 간단하니 더 쉽게 적용하실 수 있을 것 같습니다.

system call 횟수를 줄이려면 mmap() 으로.
open()/mmap()/munmap()/close() 네번에 추가적으로 필요한 만큼의 msync() 횟수가 고작입니다.
... 크기가 크다면 64bit OS 로 address space 를 극복해야겠죠.
LFS 를 써야 size_t, off_t 도 64bit 가 되겠고.
(사실, 이게 가능한지는 잘 모르겠습니다. 전엔 mmap64() 니 mmap2() 니.. 뭐 이런게 있었는데말이죠.)

I/O 의 양 자체를 줄이고 싶다면 compress/decompress 밖엔 없습니다.
CPU 의 성능과 storage 의 성능에 따라 적절히 선택해야하는데,
lzma 가 실시간성이 어쩌구하며 무척 광고를 때리는군요. 압축률이 떨어지는 대신 CPU 부담이 거의 없다고 자랑합니다.
오래 전, 150MHz MIPS CPU 에서 ROM 에 파일시스템을 구성할 때,
romfs 보다는 lzramfs 가 훨씬 더 압도적인 성능을 보이던 것을 기억하고 있습니다.
cramfs 는 ... gzip 이라 압축률은 종은데 CPU 가 받쳐주질 못해서 romfs 보다도 성능이 떨어지더군요.
레코드별로 압축을 하던가, 엔트리별로 압축을 하던가해서 I/O 를 하시면 될텐데,
헤더를 기록하기 위한 추가공간 부담이 있습니다.

OTL

system call회수를 줄이는게(bulk i/o) 일반적인 환경이라면 아마 맞는 접근 방법일 것 같은데요.

그리고 파일이 커졌을 때 얼마나 seek time에 영향을 미치는지는 댓글을 읽다보니 궁금해지네요.

그래도 HDD가 명색이 random access 장치인데 얼마나 차이가 날지...

seek를 호출 회수를 개선하는 방향이 어떨까 합니다만 이건 무척 들인 노력에 비해 소득도 적을 것 같다는

생각입니다.

분산된 파일 찾기 + 작은 파일의 short(?) seek vs. 큰 파일에서의 long(?) seek. 쯤 되려나요?

일단, 제 생각에는 지금 하시는 프로젝트의 대략의 i/o volume을 산출을 해보시고 그 양이

장비에서 어느 정도 충족하는가를 확인하시는게 선행되어야 하지 않을까 싶네요.

다른 분이 말씀하신대로 raw모드를 이용해서 하면 좋을 수도 있겠지만, 비유를 하자면

TCP/IP쓰는데 병목 일어난다고 raw socket으로 열고 프로토콜 만들어서 성능 끓어올려보겠다는

얘기나 마찮가지 같은데 이건 정말 가시밭길 일 것 같습니다(최대의 결과가 나올 수 있는 방법이긴 하지만

현실을 고려하면 결코 최선일 경우가 흔치 않을 듯).

전송량이 안나올 땐 회선 bandwidth부터 먼저 확인해 보듯이 개발 장비, 상용장비 그리고 i/o 요구량 등을 확인해 보시는게 옳은 순서 아닐까 싶습니다.