sync2000년에 Cisco Systems에서 근무하면서 Linux를 처음 접했을 때 파일 시스템 손상/데이터 손실을 방지하기 위해 버퍼를 디스크에 플러시하는 데 사용되는 이 명령의 장점에 대해 배웠습니다 . 그곳의 동료들뿐만 아니라 대학 친구들도 항상 sync한 번이 아닌 "몇 번" 또는 "여러 번", 즉 5~10번 정도 달리라고 말했습니다.
나는 그 이후로 이 습관을 계속해왔습니다. 그런데 그렇게 하면 어떤 이점이 있습니까? 다른 사람이 이에 대해 들어본 적이 있나요? 결론적으로, sync효과가 있으려면 여러 번 실행해야 한다는 당신의 생각에 대해 타당한 이유/실증적 증거를 제공할 수 있는 사람이 있습니까?
답변1
들었습니다(죄송합니다. 위치를 잊어버렸습니다). 명령을 sync세 번 입력하세요(예: S Y N C Return, 프롬프트 대기, 반복, 반복). 또한 디스크가 OS에 모든 것이 정상이라고 알린 후에도 버퍼 플러시를 완료하는 데 몇 초가 걸리는 특정 시스템이 원본이라는 것을 읽었습니다. 명령을 두 번 더 입력하면 디스크가 안정화되는 데 충분한 시간이 제공됩니다. 수년에 걸쳐 목적이 잊혀지고 조언이 축약된 것 같습니다. sync; sync; sync이는 원하는 효과를 얻지 못할 것이기 때문입니다(디스크가 "모두 지워짐"을 보고했기 때문에 두 번째 및 세 번째 동기화는 프롬프트가 너무 일찍 돌아오면서 즉시 완료됩니다). .
나는 여러 작업이 사용되는 시스템에 대해 들어본 적이 없으며 sync어떤 시스템이 존재하는지 매우 의심스럽습니다. 제 생각엔 이건 도시전설인 것 같아요. 반면에 일부 시스템에서는 동기화 후 전원이 꺼지기 전에 몇 초 정도 기다려야 한다는 사실을 발견했는데, 이는 꽤 그럴듯한 일입니다.
Google 검색을 통해 몇 가지 독립적인 동시성 분석이 이루어졌습니다.범례 동기화. 당신은 또한 볼 수 있습니다Linux를 종료하기 전에 sync(8)를 실행해야 합니까?.
답변2
TAPE의 전성기 시절, 연속 3번의 빠른 동기화는 TAPE 컨트롤러에게 테이프 스트림의 연결을 해제/풀 뿐만 아니라 되감기도 하도록 지시하는 방법이었습니다. 즉, FD/rw-head를 0으로 설정했습니다.
"sync;sync;sync"는 실제로 TAPE 기반 Unix를 처음 접하는 사람들, 즉 당시 사용 가능한 가장 저렴한 저장소인 /var/spool에 파일이 설치된 응용 프로그램에서만 효과적으로 사용되었습니다. ;)
MIPS Risc/OS 운영자 매뉴얼에는 이에 대한 페이지가 있습니다.
답변3
물론 일부 이전 UNIX 시스템에서는 다중 동기화가 더 안전하지만 모든 동기화가 단일 명령줄에서 "동기화; 동기화; 동기화"되는 것은 아닙니다. 1980년대 중반에 이는 다음과 같이 개선되었습니다.
시스템을 종료할 때 3번 동기화해야 합니다. 그 이상도 이하도 아닌. 동기화 횟수는 3이고 동기화 횟수는 3입니다. 세 번째 동기화를 계속하지 않는 한 네 번 동기화하거나 두 번 동기화할 수 없습니다.
그 세 번이 어디서 나온 것인지는 잘 모르겠지만, 어쩌면 재미있을 수도 있습니다. 그런데 길거리에서 하는 말이 두 번이나 이루어졌다. "sync;sync"가 아니라 셸에서 두 개의 개별 라인으로 표시됩니다.
V7 UNIX 시절에는 파일 시스템 복구가 그다지 재미있지 않았습니다. 이 작업은 파일 시스템의 작동 방식과 dcheck, ncheck, icheck와 같은 프로그램의 특성을 이해하고 수동으로 수행해야 합니다. fsck가 있는 경우 항상 신뢰할 수 있는 것은 아닙니다.
이것은 "우리는 눈 위를 양방향으로 걸었다"는 이야기처럼 들립니다. 글쎄요, 재시작이나 종료와 같은 멋진 명령은 없습니다. 시스템을 다시 시작하려는 경우 sync를 사용하여 파일 시스템을 동기화한 다음 콘솔에서 Ctrl-P를 눌러 중지할 수 있습니다.
sync 명령이 종료되면 커널은 예약된 동기화를 가지지만 모든 버퍼(가장 중요한 파일 시스템 수퍼블록 포함)가 반드시 디스크에 도달한 것은 아닙니다. 따라서 동기화를 실행한 다음 안전해지기 전에 중지하는 것은 매우 쉽습니다.
동기화를 다시 실행하는 것은 쉽고 시간이 많이 걸리며 모든 것을 이해하거나 "10까지 세기"와 같은 모호한 지침을 처리하지 않고도 직관적인 매력을 느낄 수 있습니다.
V7 매뉴얼 페이지에는 다음과 같은 BUG 섹션도 있습니다 update.
업데이트를 실행할 때 동기화를 수행하는 동안 CPU가 멈추면 파일 시스템이 손상될 수 있습니다. 이는 부분적으로 NPR 요청이 실패할 때 DEC 하드웨어가 0을 쓰기 때문입니다. 수정 사항은 sync(1)이 시스템 시간을 일시적으로 30초 이상 늘려 업데이트 실행을 트리거하도록 하는 것입니다. 이는 CPU 중지를 위한 30초의 유예 기간을 제공합니다.
(그런데 이게 V7 매뉴얼 1권의 마지막 내용입니다)
시간이 지남에 따라 시스템을 종료하고 다시 시작하는 파일 시스템 도구와 프로그램이 향상되어 이 문제를 처리할 필요가 없습니다. 시스템이 신비롭게 작동하면 민속, 마법, 시스템 마법이 그 시스템에 들어갑니다. 두 번 동기화하면 파일 시스템을 다시 조립하기 위해 핀셋을 꺼내야 할 가능성이 훨씬 줄어들므로 의식의 일부가 됩니다. 많이 하다 보면 아무 생각 없이 하게 될 것이다. 그러던 중 누군가가 눈치채고 이유를 물었습니다. 대답은 이렇습니다. "항상 이렇게 하세요. 그게 더 안전해요."
나는 이것이 권위 있다고 주장하지 않을 것이며 일부 세부 사항에 대해서는 틀릴 수도 있습니다. 하지만 제 생각에는 원점에 꽤 가깝습니다.