시스템 호출은 파일 시스템에 정확히 어떤 역할을 합니까 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_POWER_OFF, NULL)?
아직 메모리에 캐시된 일부 데이터가 손실된다는 점을 이해하지만 umount()이전에 해당 데이터를 호출하지 않거나 마운트 해제에 실패하면 다시 직접 연결할 reboot()수 없는 손상된 파일 시스템이 생길 가능성이 있습니까 ?mount()
나는 이것이 파일 시스템 유형에 따라 다르다는 것을 알고 있으므로 저널링 파일 시스템과 ext2와 같은 더 간단한 파일 시스템에 대해 더 자세히 알고 싶습니다.
답변1
파일 시스템을 마운트 해제하면 관련된 모든 메모리 캐시 데이터가 동기화됩니다. restart() 호출은 파일 시스템을 완전히 마운트 해제하지 않기 때문에 데이터가 손실될 수 있습니다. (lennart는 이것에 만족하지 않습니다 :-).
그러나 파일 시스템이 저널링(또는 이에 상응하는 기능)을 사용하지 않는 경우에만 "손상"이라고 부릅니다. 그 외에도 ext4/xfs/btrfs는 로그를 사용하여 100% 안정적으로 수정되어야 합니다. 이는 자동으로 발생할 수 있습니다. 전체 검사/복구와 달리 전체 파일 시스템을 검사하지 않으므로 속도가 매우 빠릅니다. 당신이 하나 가지고 있지 않는 한많은정렬해야 하는 동기화되지 않은 메타데이터 변경 사항입니다.
여기에서 ext4의 일부 샘플 메시지를 볼 수 있습니다."복구 로그"가 비정상 종료/제거를 증명합니까?
연결된 예에서는 fsck.ext4로그가 복원된 것으로 나타납니다. 하지만 나는생각하다커널은 파일 시스템이 마운트될 때 자동으로 ext4 로그를 복원할 수도 있습니다. xfs/btrfs의 경우 fsck아무 작업도 수행되지 않으므로(관련 man페이지 참조) 항상 커널에 의해 처리됩니다.
그에 비해 ext2일기장은 없습니다. fsck.ext2좋은 평판을 갖고 있지만, 내가 아는 바로는 일기가 가능한 모든 상황을 다룰 수는 없습니다. 결국 파일 이름이 손실되고 해당 내용이 lost+found디렉터리에 저장될 수 있습니다. 또는 올바른 수정 사항이 100% 명확하지 않을 수 있으므로 최선의 추측을 적용하기 전에 사용자 권한을 요청해야 합니다.
위의 내용은 저장 장치가 파일 시스템의 기대치를 충족한다고 가정합니다. 예를 들어, 쓰기 작업을 중단시키는 정전과 관련된 알려진 상황이 있습니다. 일부 SD 카드 기반 저장소에서는 쓰고 있는 디스크 블록(예: 4KB)이 포함된 전체 128KB 플래시 지우기 블록이 손실될 수 있습니다. 위에서 언급한 파일 시스템은 이러한 종류의 데이터 손실을 견딜 수 있도록 설계되지 않았습니다 :-).
답변2
현명하게 말하면 그렇지 않습니다. 다시 시작 및 종료 이벤트는 커널 개념이 아닌 사용자 공간 개념입니다. 대부분의 최신 Linux 배포판에서는 systemd에서 정상적인 종료 또는 다시 시작을 처리합니다. 또한 부팅 시 파일 시스템을 확인하고 사용 가능한 경우 마운트하는 데 사용되는 사용자 공간 도구입니다.
예, 파일 시스템 드라이버는 비정상적으로 종료되거나 다시 시작되는 경우에도 파일 시스템 일관성을 유지하기 위해 로깅을 구현합니다.
예, 커널은 사용자 공간 도구가 파일 시스템을 검사하고 관리할 수 있는 API를 제공합니다.