심각한 충돌이 발생하는 경우, 특히 UPS가 시스템을 계속 실행할 수 없는 경우 파일 시스템 캐싱으로 인해 일부 로그 콘텐츠가 손실되는 것 같습니다. 실험적으로 동기화 옵션을 사용하여 /var 파티션을 마운트해 보았습니다. 시작 시 디스크 소음이 눈에 띄게 증가하지만 이는 중지된 프로그램이 적절하게 실행을 시도하고 있음을 나타냅니다. 디스크가 쿵쿵거리고 아무 반응도 없이 거기에 앉아 있었습니다.
/varsync 마운트가 오류입니까, 아니면 성공하려면 relatime, strictatime 또는 noatime 옵션 중 하나가 필요합니까? 그렇다면 /var에서 이러한 옵션 중 하나를 사용해도 안전합니까?
답변1
파일 시스템 수준에서 활성화하는 것은 sync일반적으로 좋은 해결책이 아닙니다(항상 그런 것은 아님). 활성화되면 sync모든 쓰기에서 버퍼 플러시를 강제할 뿐만 아니라 (더 큰 블록을 작성하여) IO를 최적화하기 위해 쓰기 순서를 변경하는 파일 시스템의 기능을 손상시킵니다. 이로 인해 조각화가 더 높아집니다.
더 나은 해결책은 사용 중인 응용 프로그램이 무엇이든 fsync(또는 fdatasync)을 대신 사용하는 것입니다. 애플리케이션이 데이터를 쓸 때 fsync데이터를 강제로 디스크에 쓰도록 호출할 수 있습니다 . 이렇게 하면 전체 파일 시스템이 아닌 특정 데이터만 항상 동기화됩니다. 또한 fsync모든 데이터 비트가 아닌 모든 데이터를 기록한 후에 애플리케이션이 이를 호출할 수 있기 때문에 더 똑똑합니다 .
syslog-ng를 사용하는 경우 fsync각 파일 대상(문서). rsyslog에도 이 기능이 있을 수 있지만 이에 대해 잘 모르겠습니다.