Linux에서 "blockdev --flushbufs"와 "sync"의 차이점은 무엇입니까?

파일 시스템 계층을 거치지 않고 드라이브(예: dd)에 I/O가 이루어지면 동기화가 정말 비효율적인가요?

이것은 다음과 같은 질문을 던집니다: 장치 노드에 쓰는 것은 "파일 시스템 계층"을 우회합니다. 어떤 의미에서는 분명히 그럴 것 같은데...

어쨌든 그것은 중요하지 않습니다. 캐싱과 관련되지 않은 작업을 수행하는 경우 sync해당 작업(또는 이와 유사한 작업)을 실행하는 것은 어쨌든 "비효율적"이지 않습니다. 동기화할 항목이 없으면 사소한 호출입니다.

언제 다른 것을 사용해야 합니까?

나는 이것이 특정 파티션을 목표로 삼고 싶을 때 blockdev의미가 있다고 생각합니다. sync다른 방법에 비해 특별한 이점이 있다고 생각하지 않습니다 (또는 그 반대).

blockdev --flushbufs기본 드라이버/하드웨어에 의해 구현된 경우 장치 자체의 쓰기 버퍼가 플러시됩니다. 엔터프라이즈 하드웨어 블록 장치에서 더티 쓰기 버퍼는 일반적으로 배터리가 지원되지 않는 한 유지되지 않으며 하드웨어를 이동하거나 배터리를 교체하기 전에 여전히 플러시해야 합니다(이 작업은 일반적으로 종료 프로세스가 끝날 때 자동으로 수행됩니다. ACPI 종료 또는 재설정 전).

대부분의 기업 및 고급 데스크톱 기계식 드라이브에는 쓰기 캐시를 수행할지 여부를 구성할 수 있는 읽기/쓰기 캐시가 있으며, 이는 이 ioctl을 사용하여 플러시되는 캐시입니다. 동기화를 수행한 후에도 USB 또는 eSATA에 연결된 블록 장치를 분리하기 전에 모든 데이터가 플러시되는지 확인하는 것이 유용할 수 있습니다.

이 ioctl은 항상 신뢰할 수 있는 것은 아니며 일부 드라이버나 장치는 구현이 부족하거나 호출을 가로챌 수 있습니다. IIRC 이전 버전의 LVM도 논리 볼륨에서 사용될 때 이 ioctl을 가로채며 물리적 장치를 새로 고칠 수 없습니다.

sync()/syncfs()/fsync()/fdatasync()다른 목적을 가지고 있으며 기록되지 않은 모든 데이터/메타데이터를 장치에 다시 동기화합니다. 이 데이터에는 더티 mmap()페이지, VFS 계층의 더티 버퍼 및 커밋되지 않은 파일 시스템 변경 사항이 포함될 수 있습니다 . fdadasync()특정 파일에 대한 데이터만 플러시되므로 이는 데이터 변경 사항을 플러시하는 가장 효율적인 방법입니다(필요하지 않은 경우 파일 크기 변경과 같은 일부 메타데이터 업데이트가 여전히 지연될 수 있음). 다른 모든 sync()호출은 파일, 파일 시스템 또는 모든 파일 시스템의 모든 것을 플러시합니다. 데이터가 중요하다고 생각되면 데이터를 동기화하는 것이 프로그램의 작업이어야 합니다. 모든 것이 올바르게 기록되었는지 확인하기 위해 전체 동기화 호출에 의존해야 한다면 분명히 훨씬 덜 효율적입니다(프로그램은 sync특정 파일 시스템이나 파일 데이터를 동기화할 수도 있음). , 보다 man sync).

목표가 장치를 제거하는 것이고 장치를 마운트 해제할 수 있는 경우 동기화할 필요조차 없습니다. 파일 시스템을 마운트 해제하면 이미 OS 수준에서 모든 버퍼가 플러시됩니다( blockdev --flushbufs대형 쓰기 캐시가 있고 바로 장치 연결을 끊는 경우). 여전히 필요할 수 있습니다). 시스템 상태가 좋지 않고 제거할 수 없는 경우 재부팅하기 전에 동기화하는 것이 아마도 차선책일 것입니다(먼저 시스템에 쓰고 있을 수 있는 응용 프로그램을 모두 종료해 보십시오).

fsck또한 블록 장치의 쓰기 캐싱은 쉽게 데이터 손실로 이어질 수 있지만 대부분의 최신 저널 파일 시스템은 정전 후에도 실행할 필요가 없을 정도로 이를 잘 처리합니다 (파일 시스템의 저널에는 알려진 양호한 상태로 수정된 메타데이터가 있습니다). OTOH 이는 파일 시스템의 파일 데이터에는 해당되지 않는 경우가 많으며 잘못 설계된 응용 프로그램이 제대로 새로 고쳐지지 않으면 파일이 손상될 수 있습니다.