syslog.1일부 메시지로 가득 차 있고 크기가 77GB인 파일을 비우려고 합니다 . 내가 해냈어
sudo truncate -s 0 /var/log/syslog.1
그러나 명령이 반환되는 데는 2시간 이상이 소요됩니다. Ctrl-C 또는 kill명령을 통해 중지해도 안전합니까? 이러한 방법으로 인해 파일 시스템 불일치가 발생할 수 있습니다. 더 좋은 방법이 있나요?
시스템은 우분투 16.04입니다. 파일 크기가 갑자기 증가하고 해당 파일이 있는 루트 파티션이 /var/log/syslog.1거의 가득 찼습니다. 후속 파일은 계속해서 커지지만 명령줄은 여전히 응답합니다./var/log/syslog/var/log/kern.log
답변1
프로세스를 중단해도 파일 시스템 자체는 손상되지 않습니다. 커널은 이를 보장합니다. 최악의 시나리오는 파일이 애플리케이션 불변성과 관련하여 일관되지 않은 상태에 있다는 것입니다. 예를 들어, 파일을 저장하는 동안 파일 편집기를 종료하면 절반만 작성된 파일이 남을 수 있지만 다른 파일은 손상되지 않습니다.
이 truncate유틸리티는 ftruncate뒤에서 시스템 호출을 호출합니다. 이 시스템 호출은 원자적입니다. 발생하거나 발생하지 않습니다. 따라서 프로세스를 종료하면 truncate최종 결과는 파일이 truncate아직 실행되지 않은 것처럼 원래 상태로 유지되거나 파일이 잘리는 것입니다. 단축되었지만 완전히 잘리지 않은 파일로 끝날 수는 없습니다.
파일을 잘라도 디스크의 데이터를 덮어쓰지 않습니다. 파일의 사용된 차단 목록과 사용 가능한 차단 목록만 업데이트합니다. 데이터 블록 자체는 업데이트되지 않습니다. 나중에 데이터를 저장하기 위해 재활용될 때 덮어쓰게 됩니다. 파일이 크더라도 오래 걸리지 않습니다. 77GB의 로그를 저장할 수 있는 공간이 있는 하드웨어에서는 77GB의 데이터를 덮어쓰는 데 몇 시간이 걸리지 않습니다. 그래서 뭔가 나쁜 일이 일어났을 가능성이 높습니다. 전체 디스크에서 성능이 저하되는 병리학적 사례가 있을 수 있지만 그럼에도 불구하고 시스템이 몇 초 정도 느려질 것으로 예상합니다. 우선 순위가 높은 디스크에 다른 쓰기 작업이 있으면 몇 시간이 아니라 몇 분 정도 걸릴 수도 있습니다. . 더 가능성 있는 가능성은 디스크에 문제가 있다는 것인데, 이는 대부분 우연의 일치입니다. 커널 로그를 확인하십시오. 디스크에 문제가 있는 경우 이에 대한 메시지가 표시됩니다. 디스크 상태도 확인하세요지능형 제어.
그런데, syslog.1이 파일은 아카이브 파일이므로 다른 내용은 기록되지 않습니다. 비우는 것보다 삭제하는 것이 좋습니다.
커널이나 하드웨어 오류가 없는 한 이는 프로세스 종료 여부에 관계없이 발생할 수 있습니다.