Linux가 응답을 멈추면 사람들은 강제로 불규칙한 종료를 수행해야 할 수 있으며, 이 경우 자신도 모르게 전원이 꺼질 수 있습니다. 가능하다면 갑자기 전원이 꺼지면 파일 시스템이 손상될 수 있으므로 ctrl+prntSc + R +E +I + S+ U+ B를 사용하여 Linux의 소프트 재설정을 시도해야 한다는 내용을 읽었습니다. 구체적인 내용은 무엇입니까? 이 경우 Linux는 MS-Windows보다 탄력성이 떨어지나요?
답변1
Ctrl+PrtScr나는 그것이 당신이 필요로 하는 것에 대해 많은 일을 할 것이라고 생각하지 않습니다 SysRq(일반적으로 와 동일한 물리적 키에 있고 PrtScr키를 눌러 액세스하므로 "마법"조합이 실제로인지 아닌지는 Alt약간 불분명합니다 ).SysRq+<letter>Alt+SysRq+<letter>
이 B기능은비oot 시스템이므로 콤보는 시간 낭비이고 B수행만 가능하며 부팅하는 것만으로도 전원을 껐다 켜는 것만큼 나쁩니다.
(때때로) 달성할 수 있는 것 SysRq+R,E,I,S,U,B(나에게 +이것은 한 번에 모든 키를 눌러야 하며 한 번에 8개의 키를 누르는 것이 어렵다는 것을 의미합니다. 원하는 작업이 아닙니다. 실제로 "BUSIER"는 완전히 거꾸로 된 고전적인 조합입니다) , 가능한 한 많은 데이터가 디스크에 잘 기록되므로 다음 부팅 시 fsck가 필요하지 않으며 데이터 손실 위험이 최소화되는 더 나은 종료 방법입니다.
SysRq 조합의 전체 목록과 일부 니모닉을 포함하여 많은 정보가 있습니다.Magic SysRq의 Wikipedia 페이지.
답변2
구체적인 내용은 무엇입니까? 이 경우 Linux는 MS-Windows보다 탄력성이 떨어지나요?
어떤 시점에서는 비교가 유용할 수 있습니다. 이 비교를 통해 이러한 SysRQ 명령이 잘 알려진 이유를 설명할 수 있습니다. 그러나 최신 Linux와 Windows 버전을 비교하는 데는 작동하지 않습니다.
"저널링 파일 시스템"이 무엇을 의미하는지 이해한다면 자세한 내용은 대부분 설명됩니다. 예시 참조.
이 참고자료에 따르면 대부분의인기 있는Linux 파일 시스템 제품군은 Microsoft보다 늦게 저널링 파일 시스템 지원을 받았습니다.
또한 일반적인 이해는 Linux 파일 시스템이 여전히 꽤 잘 복구할 수 있다는 것입니다 fsck. 문제는 fsck더 큰 디스크에서는 시간이 오래 걸리기 때문에 로깅이 더 최적화된다는 것입니다.
최신 대형 디스크에서 이 작업이 수행되는 데 걸리는 시간을 고려하면 로깅이 더욱 "복원력"이 높아졌다는 점은 의심할 여지가 없습니다. :-). 원칙적으로 동기화는 저널링 파일 시스템에 관계없이 일부 용도로 사용될 수도 있습니다. 이를 통해 동기화되지 않은 파일 내용을 포함하는 즉시 쓰기 저장을 트리거할 수 있습니다. (그런 다음 쓰기 저장이 완료되는 시점을 추측하려면 디스크 LED나 소음을 관찰해야 합니다.) dirty_writeback_centisecs예를 들어 이렇게 하면 ext 파일 시스템을 기다릴 필요가 없습니다 . 어떤 사람들은 시스템을 구성하여 사용하기도 합니다."노트북 모드"게으른 쓰기 저장은 전력을 절약하기 위해 무기한 지연됩니다.
한 가지 추가 세부 사항이 있습니다. Linux의 저널링 파일 시스템은 barriers비활성화된 상태에서 실행 되지 않는다고 가정하는 경향이 있습니다 . 장벽이 성능에 미치는 영향이 완화되었으며 Linux 배포판에서는 기본적으로 장벽 비활성화를 중지했습니다. (또는 특정 상황과 일부 하드웨어에서는 장벽을 비활성화하는 것이 "안전"할 수 있지만 이는 2018년 현재 일반적인 PC 하드웨어에는 적용되지 않습니다. Redhat은 해당 하드웨어에서 장벽 비활성화 권장을 중단했습니다.)예시 참조.
인용문(일부 형식 - 유용한 링크 - 누락됨):
저널 파일 시스템
파일 및 디렉터리의 변경 사항을 반영하도록 파일 시스템을 업데이트하려면 별도의 쓰기 작업이 많이 필요한 경우가 많습니다. 이로 인해 쓰기 간 중단(예: 정전 또는 시스템 충돌)이 발생하여 데이터 구조가 유효하지 않은 중간 상태가 될 수 있습니다. [1]
예를 들어 Unix 파일 시스템에서 파일을 삭제하려면 다음 세 단계가 필요합니다. [5]
- 해당 디렉토리 항목을 삭제하십시오.
- inode를 사용 가능한 inode 풀에 해제합니다.
- 사용된 모든 블록을 여유 디스크 블록 풀로 반환합니다.
1단계 이후와 2단계 이전에 충돌이 발생하면 분리된 inode가 발생하여 스토리지 누수가 발생합니다. 반면, 충돌이 발생하기 전에 2단계만 먼저 수행하면 삭제되지 않은 파일은 무료로 표시되어 다른 콘텐츠로 덮어쓸 수 있습니다.
이러한 불일치를 감지하고 복구하려면 fsck(파일 시스템 검사기)와 같은 도구를 통해 데이터 구조를 완전히 이해해야 하는 경우가 많습니다. [2] 이는 일반적으로 읽기 및 쓰기 액세스를 위해 파일 시스템이 다음에 마운트되기 전에 수행되어야 합니다. 파일 시스템이 크고 I/O 대역폭이 상대적으로 작은 경우 시간이 오래 걸릴 수 있으며 시스템의 나머지 부분이 다시 온라인으로 돌아오지 못하게 하면 가동 중지 시간이 더 길어질 수 있습니다.
이를 방지하기 위해 저널링 파일 시스템은 미리 수행할 변경 사항을 기록하는 특수 영역인 저널을 할당합니다. 충돌 후 복구는 단순히 파일 시스템에서 로그를 읽고 파일 시스템이 다시 일관성을 가질 때까지 해당 로그의 변경 사항을 재생합니다. 따라서 이러한 변경 사항은 성공(처음에 성공하거나 복구 중에 완전히 재생됨)되거나 전혀 재생되지 않기 때문에(충돌 전에 로그에 완전히 기록되지 않았기 때문에 건너뛰기) 원자성(분할할 수 없음)으로 간주됩니다.
장애
정전 시 데이터 손상 위험을 줄이기 위해 일부 저장 장치에서는 배터리 지원 쓰기 캐싱을 사용합니다. 일반적으로 고급 어레이와 일부 하드웨어 컨트롤러는 배터리로 구동되는 쓰기 캐시를 사용합니다. 그러나 캐시 변동성은 커널에 보이지 않기 때문에 Red Hat Enterprise Linux 6에서는 지원되는 모든 저널링 파일 시스템에서 기본적으로 쓰기 장벽을 활성화합니다.
비휘발성 배터리 지원 쓰기 캐시가 있는 장치와 쓰기 캐시가 비활성화된 장치의 경우 -o nobarrier 옵션을 사용하여 마운트 시 쓰기 장벽을 안전하게 비활성화할 수 있습니다. 그러나 일부 장치는 쓰기 장벽을 지원하지 않습니다. 이러한 장치는 오류 메시지를 /var/log/messages에 기록합니다(표 22.1, "파일 시스템당 쓰기 장벽 오류 메시지" 참조).
[...]
노트
쓰기 장벽은 성능에 미미한 부정적인 영향(약 3%)을 갖기 때문에 Red Hat Enterprise Linux 6에서는 nobarrier 사용이 더 이상 권장되지 않습니다. 일반적으로 쓰기 장벽의 이점은 비활성화로 인한 성능 이점보다 큽니다. 또한 nobarrier 옵션은 가상 머신에 구성된 스토리지와 함께 사용하면 안 됩니다.