Brian Ward가 쓴 "How Linux Works"라는 책을 살펴보세요. 나는 일반적으로 이것에 대해 의심의 여지가 없습니다. 하지만 이것은. "6.7.0 시스템 종료"에 순서가 지정된 작업 목록이 있습니다.
읽기 전용 모드(6)에서 루트 파일 시스템을 다시 마운트한 후 버퍼링된 데이터는 동기화 프로그램(7)을 통해 기록됩니다.
읽기 전용 모드로 마운트한 후 파일 시스템에 데이터를 쓰는 방법은 무엇입니까? 버그일 수 있습니다. 올바른 순서는 먼저 버퍼에 쓴 다음(7) 마운트 해제하고(5) 다시 마운트하는 것입니다(6)?
1. init asks every process to shut down cleanly.
2. If a process doesn’t respond after a while, init kills it, first
trying a TERM signal.
3. If the TERM signal doesn’t work, init uses the KILL signal on any
stragglers.
4. The system locks system files into place and makes other preparations
for shutdown.
5. The system unmounts all filesystems other than the root.
6. The system remounts the root filesystem read-only.
7. The system writes all buffered data out to the filesystem with the
sync program.
8. The final step is to tell the kernel to reboot or stop with the
reboot(2) system call. This can be done by init or an auxiliary program
such as reboot, halt, or poweroff.
추신: 이 책은 놀랍습니다. 이것이 여러 장에서 다루는 유일한 문제입니다.
답변1
파일 시스템 드라이버(일부 블록 저장 매체의 블록을 디렉토리와 파일로 변환)가 있고 그 아래에는 캐시 계층이 있습니다(그래서 커널이 실제로 필요한 동안 저장 매체에 빠르게 데이터를 쓰고 다른 작업을 계속할 수 있습니다). 일반적으로 상대적으로 느리기 때문에 백그라운드에서 저장 장치에 데이터를 쓰는 데 신경을 써야 합니다.
sync
해당 캐시 계층에 있는 모든 항목이 스토리지에 기록되었는지 확인하세요.
따라서 이것은 파일 시스템 "아래"의 데이터에 관한 것입니다.
답변2
읽기 전용 모드로 마운트한 후 파일 시스템에 데이터를 쓰는 방법은 무엇입니까?
읽기 전용은 마운트 지점의 속성입니다. 즉, 파일 시스템을 마운트(점)하여 변경할 수 없습니다. 이는 하위 계층(예: 블록 계층 또는 캐시 계층)이 파일 시스템을 변경할 수 없다는 의미는 아닙니다. (실제로 캐시 레이어라는 것이 없을 수도 있습니다. 블록 레이어가 캐싱을 담당하는 것에 가깝습니다.내 생각엔.)
파일 시스템의 잠재적인 변경을 방지하려면 파티션이나 드라이브 자체를 어떤 방식으로든 읽기 전용으로 설정해야 합니다. (장치에 플러시되는 버퍼링된 데이터를 "차단"하는 효과가 없을 수도 있습니다 blockdev --setro
. 장치 자체가 논리 블록에 대한 쓰기 액세스를 비활성화해야 할 수도 있습니다.)
파일 및 디렉터리의 관점에서 변경 사항은 실제 저장소에 기록되었는지 여부에 따라 달라지지 않습니다. 즉, 파일 시스템 드라이버가 일부 "동기화 모드"(있는 경우)에서 실행되지 않는 한, 파일에서 읽은 내용은 파일 시스템 드라이버 새로 고침에서 읽을 때까지 쓰기 버퍼/캐시에 남아 있을 수 있습니다. 아래에. sync -f path/to/mountpoint
파일 시스템 드라이버를 요청합니다(예:). (그러나 다른 이유로 인해 새로 고침이 백그라운드에서 발생할 수 있습니다.)
Linux에서 읽기 전용 모드로 마운트를 다시 마운트한 후 명시적인 동기화/플러시가 실제로 필요한지 궁금합니다. 제거와 같은 숨겨진 문제를 일으키지 않는다는 사실에 조금 놀랐습니다.