어젯밤에 배터리가 방전되어 노트북이 강제 종료되었습니다. 재부팅 후 중단 Xorg
되고 문제 해결이 매우 어렵습니다. 내 파티션의 첫 번째 파일 시스템 검사에서는 ext4
오류가 발생하지 않았습니다. 관련 내용을 다시 확인해 보니 logs
특이한 점은 발견되지 않았습니다. 나는 사용한 이후 로 이전에 여러 번 무시했던 다음 줄을 찾은 곳을 xdm
찾았습니다./var/log/xdm.log
/usr/bin/X: symbol lookup error: /usr/lib/libpciaccess.so.0: undefined symbol: gzopen64
그러다가 전화를 했어요
apt-get install --reinstall libpciaccess
재부팅 후 모든 것이 정상으로 돌아 왔습니다.
디스크 캐시에 더 이상 물리적으로 기록할 수 없기 때문에 강제 종료로 인해 데이터가 손상될 수 있다는 점을 이해합니다. 파일 시스템 내부에 대해 더 깊은 이해가 없기 때문에 파일 시스템을 /usr/lib/libpciaccess.so.0
닫으면 왜 아픈지 궁금합니다. 특히 시스템이 공유 라이브러리에서만 읽는다는 점을 고려하면 이러한 라이브러리가 있는 섹터가 손상될 가능성은 거의 없습니다.
또한 어떤 파일 시스템이 하드 종료에 더 강한지, 어떤 파일 시스템이 하드 종료에 덜 강한지 알고 싶습니다.
시간을 내주셔서 감사합니다.
답변1
"올바른" 파일 시스템의 문제가 아니라 이를 사용하는 방법과 마운트하는 방법의 문제입니다.
ext3 및 ext4의 경우 다음을 사용할 수 있습니다.루오,동기화,디렉터리 동기화옵션.
의도 쓰기 로그가 있는 파일 시스템은 일반적으로 실제 쓰기 전에 메타데이터를 동기화하는 경우 성능이 더 좋습니다.
귀하의 경우에는 라이브러리 캐시(/etc/ld.so.cache)가 손상되었을 수 있습니다. 간단한 접근 방식으로 ldconfig
문제가 해결되었을 수 있습니다.
때로는 전체 파일 시스템 검사를 강제로 수행하여 오류를 찾아 수정해야 하는 경우도 있습니다. 때로는 이 작업을 수행하기 위해 Netboot나 CD/DVD(이미지)를 통한 복구 부팅이 필요할 수도 있습니다.
fsck -f -y ...
- 나중에 볼 수 있도록 출력을 로그 파일에 기록합니다.
그 후 문제가 있는 것으로 보고된 모든 파일/디렉터리를 확인하면 패키지가 여전히 괜찮아 보입니다(rpm 기반 시스템에서 :) rpm -V
- 데비안에는 파일이 속한 패키지를 결정하고 패키지의 무결성을 확인하는 유사한 메커니즘이 있어야 합니다 .