나는 많은 Linux 서버를 관리해 왔고 다른 어떤 운영 체제보다 Linux 서버를 사용하는 것이 더 쉽습니다. 그러나 Linux 운영 체제에서 제가 가끔 직면하는 한 가지 문제는 파일 시스템이 손상된다는 것입니다. Windows 서버에서는 이 문제가 발생하지 않습니다.
인터넷에서 해결책을 자세히 찾아봤는데 대부분은 모두가 제시한 제안이었습니다.
- 백업 및 복원 유지
내 의견 ==> 100% 동의하지만, 충돌된 OS를 복구하는 수고를 겪지 않아도 되는 해결책을 찾고 있습니다.
- fsck 실행
내 의견 ==> 내 경험상 이것은 때때로 추가적인 문제를 야기합니다.
- 적절한 종료/다시 시작.
내 의견 ==> 모두가 제대로 종료/다시 시작하기를 원합니다. 서버가 응답하지 않거나 제대로 종료하거나 다시 시작할 수 없는 드문 경우에 대해 이야기하고 있습니다.
- Btrfs==>
내 의견 ==> 생산하기에 충분히 안정적이지 않습니다.
- Ext4로 업그레이드
내 의견 ==> 이미 ext4를 사용하고 있습니다.
- 하드 드라이브를 업그레이드하세요 내 의견 ==> 우리가 직면한 문제는 디스크 오류로 인한 것이 아니라 주로 부적절한 종료로 인해 발생했습니다.
내 fsck 질문:
-y 옵션을 사용하여 fsck를 실행할 때 파일 시스템이 손상되는 경우가 있습니다.
fsck는 시스템을 복구하는 데 1~2일 정도 소요되는데 이는 프로덕션 환경에서는 적합하지 않습니다.
내 질문은 btrfs가 안정될 때까지 이 문제를 해결할 수 있는 해결 방법이 있습니까?입니다.
이는 몇 분 안에 파일 시스템을 "동기화"하는 것과 같습니다. 또는 재부팅하기 전에 모든 파일 시스템 변경 사항을 동기화하는 스크립트를 작성하십시오.
저는 조언보다는 이 문제에 대한 해결책을 찾고 있습니다.
답변1
ext4는 플러그를 뽑아도 저항할 수 있어야 합니다. 그러나 이를 수행하려면 스토리지 하위 시스템이 커밋된 쓰기를 잃지 않아야 합니다.
barrier=0
먼저 / 를 사용하여 설치 하지 않았는지 확인하세요 nobarrier
. 이렇게 하면 일반적으로 성능이 향상되지만 적절한 종료가 수행되지 않으면 손상이 발생할 수 있습니다. 또한 커널 로그를 확인하여 스택의 어떤 항목이 장벽을 지원하지 않기 때문에 ext4가 장벽을 비활성화하지 않는지 확인하세요.
다음으로 시도할 작업은 적어도 자기(SSD가 아닌) 디스크에서 디스크 쓰기 캐싱을 비활성화하는 것입니다. 때로는 데이터가 실제로 플래터에 기록되는 시점에 대해 디스크가 거짓말을 하게 되므로 성능이 향상될 수 있습니다(전원이 중단되지 않는 한). 일반적으로 hdparm -W0
(IDE/SATA의 경우) 또는 (SCSI/SAS의 경우)를 사용하여 sdparm --clear=WCE
이 작업을 수행 할 수 있습니다. 이는 특히 전원을 껐다 켜면 기본값으로 재설정될 수 있는 SATA의 경우 부팅 스크립트에 추가해야 할 수도 있습니다.
캐시에 기록해도 데이터가 손실되지 않음을 확인하는 (상당히 오래된) 스크립트가 있습니다.Brad Fitzpatrick의 diskchecker.pl 블로그 게시물스크립트와 사용 방법에 대해 알아보세요.
불행하게도 SSD를 사용하고 있는데 문제가 있는 경우 다른 디스크를 찾아야 할 수도 있습니다.