노드에 데이터를 저장하는 보관 형식을 최적화하려고합니다. 시간이 지남에 따라 컨테이너가 지저분 해집니다 (사용할 수없는 작은 "자유"공간 노드가 누적됩니다). 내가하고있는 일은 조각 모음과 비슷하다. 이미 모든 데이터 위치 목록과 데이터가 최종 상태가 될 곳을 나타내는데, 실제 데이터를 현재 구성에서 최적 구성으로 이동하는 작업에 어려움을 겪고 있습니다. 요소는 크기가 작거나 블록의 배수가 다릅니다 (바이트를 계산하지 않는 한). 내가 간과하고있는 확실한 방법이 있습니까? 이 문제가 알고리즘 검색을 위해 무엇이 불려지는지조차 알지 못합니다. 가장 가까운 곳은 적절한 정렬입니다.파일 내용 재 배열
지금까지 데이터 블록 교환을 시도했지만 노드 조각을 추적해야하며 실행 가능성이 너무 복잡합니다.
파일이 매우 크기 때문에 임시 복사본을 작성한 다음 대체하는 것에 의지하고 싶지 않습니다.
성능과 관련하여 데이터를 새 파일로 복사하는 것이 가장 좋은 방법입니다.
사용 가능한 디스크 공간이 문제가되면 빨리 처리 할 수있는 정교한 해킹 기술이 필요하기 때문에 앞서 즐거운 시간을 가질 수 있습니다. 최선의 방법은 버퍼 메모리를 대량으로 할당하고 데이터가이 버퍼 내에있는 파일의 구멍 목록을 유지하는 것입니다. 그런 다음이 버퍼에 파일의 시작 부분부터 시작하여 모든 위치가 채워지기 시작합니다. 버퍼가 가득 차면 구멍의 어느 곳에서나 데이터를 복사하고 채우는 구멍의 끝에있는 버퍼로 데이터를 계속 밀어 넣을 수 있습니다. 버퍼 공간이 부족할 때마다 사용 가능한 가장 큰 구멍을 건너 뛰고 거기에 속한 데이터를 이동해야합니다. 내가 말했듯이 이것은 쉽지 않을 것이지만 재미있을 것입니다 ...
태그는 재미있을 것입니다. 버퍼가 아직 이동하지 않는 데이터로 채워지지 않는 한. 나는 버퍼를 임시 파일로 대체 할 수있을 것이라고 생각한다. 필요하다면 전체 압축 파일의 크기에 접근해서는 안된다. – mcu17818
여유 공간을 "압축"할 때 파일 끝에 버퍼 내용을 추가 할 수도있다. 원본 EOF에 도달하면 남은 여유 공간을 자르거나 나중에 사용할 수 있도록 퇴장 할 수 있습니다. – Ioan
버퍼에 파일을 쓰는 것이 더 많은 디스크 액세스를 의미하기 때문에 파일에 쓸 시간은 가치가 없다고 생각합니다. 위에 설명 된 알고리즘을 사용하면 각 바이트를 한 번만 읽고 쓸 필요가 있습니다. 임시 파일을 사용하면이 파일이 두 번 증가합니다. 현대 시스템이 자동으로 임시 파일을 버퍼링하기 때문에 처음에는 속도가 빨라지지만 어떤 경우에도 추가 작업입니다. 물론, 당신은 항상 나를 잘못 증명하려고 노력할 수 있습니다 ...-) – cmaster
파일 시스템에 아카이브가 있기 때문에 파일 시스템이 자동으로 해당 데이터의 단어 경계를 자동으로 설정하지 않습니까? 내가 묻는 것은, 파일 시스템에 의해 야기 된 경계 때문이며, 실제로 아카이버가 아닌, 사용하기 어려운 "자유로운"공간 노드가 아닐까? – Magn3s1um
아니요, 형식은 꽤 낮은 수준이 아니며 문자 그대로 헤더와 이진 데이터가 아니며 여유 공간에는 길이가 표시되고 FREE – mcu17818