배경

카메라 데이터를 시간별 파일로 디스크에 직접 스트리밍하는 NAS 설정이 있고 하루 시작 시 24개 파일을 일일 파일로 연결하는 작업을 설정한 다음 동일한 In 하위 볼륨(사용)에 저장합니다. ffmpeg)

압축이 포함된 "라이브 카메라" 하위 볼륨이 있습니다.장애가 있는그리고 nodatacow.

의도

아이디어는 압축된 비디오 파일(압축 없음)의 btrfs 오버헤드를 최대한 제한하고 파일의 쓰기 영향(nodatacow)을 제한하는 것입니다.문서:

전체 업데이트는 자주 덮어쓰는 작업 부하의 성능을 향상시킬 수 있지만 쓰기가 중단되는 경우(시스템 충돌, 장치 오류) 부분 쓰기가 발생할 수 있다는 단점이 있습니다.

(부분 쓰기에 대해서는 크게 걱정하지 마세요. ffmpeg여전히 표시되는 부분적으로 손상된 비디오 파일을 연결할 수 있는 것처럼 보이기 때문입니다.)

문제의 핵심

그런데 설명을 다시 보니이것이 어떻게 도움이 될지는 잘 모르겠습니다: "덮어쓰기"가 비디오 파일의 긴 스트리밍에 영향을 미치는지 확실하지 않습니다.
파일 쓰기는 지속적인 덮어쓰기 동작입니까?
이 상황에서도 여전히 도움이 될까요?

질문

하위 볼륨에 대한 잠재적인 마운트 옵션에 대한 지침을 주시면 감사하겠습니다. A/B 비교를 결정하기 위해 확인할 수 있는 통계/시스템 측정항목을 알고 계시다면 그것도 좋을 것입니다!

또한

autodefrag또한 내 관심을 끌었습니다.

자동 파일 조각 모음을 활성화합니다. 활성화되면 파일에 대한 작은 무작위 쓰기(수십 KB 범위, 현재 64KiB)가 감지되어 조각 모음 프로세스를 위해 대기열에 추가됩니다. 대규모 데이터베이스 워크로드에는 적합하지 않을 수 있습니다.

다시,잘 모르겠습니다"파일에 쓰기"가 장시간 실행되는 비디오 스트림에서 작동하거나 기존 "만들기" 파일에만 영향을 미치는 경우.