답변1
당신이 요구하는 것은 단지 "역방향" 파일 시스템이 아닙니다. 당신은기록구조화된, "역방향" 파일 시스템, 즉 마지막에 추가된 레코드가 파일에서 처음으로 나타나는 레코드 파일 시스템입니다. 실제로 반대 측면은 아마도 "첫 번째 기존 레코드 앞에 레코드를 삽입할 수 있습니다"로 구현될 것입니다.
일반적으로 PC(Unix, Windows 및 훨씬 더 특이한 운영체제)에서 발견되는 운영 체제에 있는 파일 시스템 인터페이스는 바이트 구조로만 구성되어 있으며 레코드 개념이 없습니다. 그래서 당신은 운이 없습니다.
한 가지 가능한 접근 방식은 각 로그 항목을 디렉터리에 별도의 파일로 만드는 것입니다. 그런 다음 파일 생성 시간의 역순으로 디렉터리를 탐색하거나, 로그 항목에 단조롭게 증가하는 이름을 지정하는 경우 이름의 역순으로 탐색합니다. 로그 항목이 많을 가능성이 높으므로 큰 디렉토리를 잘 지원하는 파일 시스템을 사용하거나(예: Linux reiserfs 및 기능이 있는 ext3은 dir_index괜찮지만 ext2는 그렇지 않음) 하위 디렉토리를 사용하십시오(하나는 처음 1000개 항목에 대해, 다음 1000개 항목에 대해 하나 등).
또 다른 접근 방식은 보다 정교한 데이터베이스(예: SQL로 쿼리할 수 있는 데이터베이스)를 사용하고 생성된 레코드를 역순으로 선택하는 것입니다( SELECT message FROM logs ORDER BY date DESC).
답변2
나는 그런 것이 존재하는지 완전히 확신하지 못하지만, 확실히 들어본 적이 없습니다. 그렇게 할 수 있다면 몇 가지 큰 단점이 있을 것이라고 생각합니다.
파일 앞에 추가하려면 일반적으로 기존 데이터의 전체 복사본이 필요합니다. 파일 시스템에서는 파일 시작 부분에 블록을 추가하는 것으로 처리할 수 있지만 여전히 몇 가지 사소한 문제가 발생합니다. 여유 공간이 있는 블록은 처음부터 여유 공간을 유지해야 하므로 적절한 위치를 찾으려면 드라이브에서 추가 탐색이 필요할 가능성이 높습니다.
뒤로 작업할 때 드라이브의 여유 공간을 처리하는 것은 큰 고통이 될 것입니다. 이는 최대 인덱스를 찾은 다음 거기에서 다시 작업해야 하기 때문에 대부분의 프로그래밍 기술과 모순됩니다.
대용량 파일에서는 속도가 느려지고 프로그래밍하기에는 확실히 터무니없는 일이 될 것이라고 상상할 수 있습니다.
역방향 파일 시스템을 찾는 대신 단순히 평소대로 파일을 작성하고 역방향으로 구문 분석하면 안 될까요? 기본 메시지 형식 구성표를 작성하고 파일을 읽고 메시지를 구문 분석한 다음 마지막에서 처음으로 표시합니다. 마지막 메시지만 필요한 경우 파일 끝을 찾은 다음 뒤로 돌아갑니다.N메시지. 결과는 비슷하지만 작업량이 훨씬 적고 성능이 비슷하거나 더 좋습니다.
답변3
의 생각을 분리해야 합니다.저장그리고검색. 당신이 언급한 블로그에도 해당 항목이 있을 가능성이 높습니다.저장됨시간순으로 진행되지만,표시됨시간 역순으로(구조화된 저장소를 사용하면 더 쉬워진다는 사실을 무시함)
고정 길이 형식(64비트는 64비트)의 리소스 파일에 저장된 바이트 오프셋 포인터가 있는 자유 형식 및 가변 길이의 "레코드"를 사용하여 친숙한 정방향 순서로 항목을 저장하는 단순한 구조의 저장 시스템을 만들 수 있습니다. 1,800만 테라바이트가 넘는 지원 파일). 마지막 레코드나 nth레코드 또는 last - n포인터 파일의 레코드를 검색하면 기본 파일에서 가리키는 바이트가 사소하고 빠릅니다. 특수 파일 시스템이나 드라이버가 허용하는 트릭은 이 원자성을 만들고 리소스 파일을 투명하게 만드는 것입니다.
답변4
두 가지 생각이 떠오른다:
일부 버전 제어 시스템은 제어된 파일의 첫 번째 버전을 전체 버전으로 저장하고 모든 후속 버전을 변경 사항으로 저장하는 반면, 다른 시스템은 제어된 파일의 현재 버전을 전체 버전으로 저장하고 모든 이전 버전을 변경 사항으로 저장합니다.
플랫 파일이 아닌 데이터베이스에 런타임 이벤트를 기록하는 경우 데이터베이스가 이벤트를 순차적으로, 역순차적으로 또는 무작위로 저장하는지 여부가 불투명할 수 있습니다.