(스택 오버플로에서 이동했습니다.)
여러 파일을 USB 플래시 드라이브에 복사하는 간단한 백업 프로세스가 있습니다. 플래시 드라이브를 다시 읽고 원본 파일과 비교하여 복사가 성공했는지 확인하고 싶습니다. 다시 읽으면 Linux가 캐시한 데이터만 반환하는 것이 아니라 플래시 드라이브를 읽는지 확인하고 싶습니다. (플래시 드라이브에 내부 캐시가 있었으면 좋겠지만 걱정하지 않습니다.) Linux가 특정 파일 시스템(또는 특정 드라이브 파티션)에 대해 캐시된 정보를 삭제하도록 프로그래밍 방식으로 어떻게 보장할 수 있습니까? (플래시 드라이브를 마운트 해제하고 물리적으로 제거했다가 다시 삽입할 수 있지만 프로그래밍 방식의 솔루션을 선호합니다.)
현재 파일 시스템을 마운트 해제한 다음 마운트하고 있는데, 이로 인해 Linux가 "파일별로" 구성된 캐시 데이터를 삭제할 것으로 예상됩니다. 그러나 이에 영향을 받지 않는 "파티션별" 또는 "장치별"로 구성된 하위 수준 블록 캐시가 있을 수 있습니다.
알고 있지만 echo N >/proc/sys/vm/drop_caches이렇게 하면 모든 파일 시스템에 대한 캐시 블록이 삭제됩니다. 이는 필요한 것보다 더 광범위하고 다른 파일 시스템에서 성능 저하를 일으킬 수 있습니다.
이를 위해 잘 작동하는 blockdev 명령이 있지만 캐시를 삭제하는 옵션이 없습니다(Linux 5.17.12 기준). (그렇지만 --flushbufs나에게 필요한 것은 아닙니다.)
답변1
다음은 가능한 해결 방법이지만 이상적이지는 않습니다. 이전 버전의 백업 프로세스로 인해 백업 중인 파일 트리에 대해 ISO 9660 파일이 생성된 것으로 나타났습니다. dd oflag=direct블록이 캐시에 저장되지 않도록 다음 명령을 사용하여 ISO를 백업 미디어에 복사할 수 있습니다 . 그런 다음 사용할 수 있는 백업을 확인하려면 cmp미디어에서 블록을 읽어야 합니다. ISO 파일을 어딘가에 마운트하면 트리의 개별 파일에 액세스할 수 있습니다.
쓰기는 캐시를 우회하므로 드라이브의 "마모"를 줄이기 위해 일괄 쓰기에 커널의 영리한 알고리즘을 활용하지 못할 수 있습니다. 이는 작성된 페이지 전체가 포함된 블록을 전송하면 피할 수 있는 것 같습니다. 플래시 드라이브의 쓰기 페이지는 일반적으로 64kiB 이하이므로 dd bs=128K몇 년 동안 지속하기에 충분할 것입니다.
그리고 dd꼬리 부분 블록도 제대로 복사된 것 같습니다.
cp직접 쓰기 옵션이 없는 것 같습니다.