2000 년 Cisco Systems에서 일하면서 Linux를 처음 소개했을 때, sync파일 시스템 손상 / 데이터 손실을 방지하기 위해 버퍼를 디스크로 플러시하는 데 사용되는 명령 의 장점을 배웠습니다 . 나는 동료들뿐만 아니라 대학 친구들이 sync"한 번"대신 "몇 번"또는 "다발"을, 즉 5-10 번 정도 달리라고 들었 습니다.
나는 그 이후로이 습관을 계속했지만 이것에 대한 장점이 있습니까? 다른 사람이 이것을 들어 본 적이 있습니까? 그리고 가장 중요한 것은 누구나 sync효과를 발휘하기 위해 두 번 이상 실행해야한다는 아이디어에 대한 합리적인 근거 / 경험적 증거를 제공 할 수 있습니까?
답변:
sync명령을 세 번 입력하는 것으로 들었습니다 (죄송합니다, 어디에서 잊어 버렸는지) : S Y N C Return프롬프트에서 기다렸다가 반복하고 반복하십시오. 또한 오리진은 운영 체제에 모든 것이 정상이라고 말한 후에도 디스크가 버퍼 플러시를 완료하는 데 몇 초가 걸리는 특정 시스템이라는 것을 읽었습니다. 명령을 두 번 더 입력하면 디스크에 충분한 시간을 확보 할 수 있습니다. 수년에 걸쳐 그 목적이 잊혀진 것 같고 조언은 sync; sync; sync원하는 효과를 갖지 못했던 조언으로 축약 된 것 같습니다 (디스크가“모두 클리어”를보고했기 때문에 두 번째와 세 번째 동기화가 즉시 완료되고 프롬프트가 너무 일찍 돌아올 것입니다).
여러 sync작업에서 사용 하는 시스템에 대해 들어 본 적이 없으며 , 회의적인 의견이 많습니다. 나는 이것을 도시의 전설이라고 생각합니다. 반면에 동기화 후 및 전원을 끄기 전에 몇 초 동안 기다려야하는 시스템이있을 것입니다.
인터넷 검색은 몇 가지 독립적 인 동의 분석 (예 : The Legend of sync)으로 이어 집니다. 참조 동기 (8)의 실행 여전히 리눅스 종료하기 전에 필요한? .
옛날 타이머. TAPE의 영광스러운 시대로 돌아가서, 3 개의 빠른 동기화는 TAPE 컨트롤러에게 테이프 스트림을 링크 해제 / 스풀 해제 할뿐만 아니라 되감기, 즉 FD / rw-head 설정을 지시하는 방법이었습니다. 0
"sync; sync; sync"는 TAPE 기반 Unix로 치아를 절단 한 사람들, 즉 파일이 / var / spool에 마운트되어 당시 가장 저렴한 저장 용량을 가진 앱을 사용하는 사람들에 의해서만 생산적으로 사용되었습니다. ;)
MIPS Risc / OS 사용 설명서에는이 페이지가 있습니다.
확실히 이전 UNIX 시스템이 두 번 이상 동기화하는 것이 더 안전했지만 한 명령 행에서 모두 "sync; sync; sync"로 실행되는 것은 아닙니다. 80 년대 중반, 이것은 다음과 같이 증류되었습니다.
시스템을 종료하면 동기화를 세 번해야합니다. 그 이상도 이하도 아닌. 동기화의 수는 3이되어야하고 동기화의 수는 3이되어야한다. 네 번 동기화하지 말고 두 번 동기화하지 마십시오.
재미 있었다는 것만 빼고 세 번 어디서 왔는지 모르겠어요. 그러나 거리의 단어는 그것을 두 번합니다. "동기화; 동기화"가 아니라 셸에서 별도의 두 줄로 표시됩니다.
예를 들어, V7 UNIX 시절에 파일 시스템 복구는 그리 재미 있지 않았습니다. 파일 시스템의 작동 방식과 dcheck, ncheck 및 icheck와 같은 프로그램의 특유성에 대해 많은 것을 알고 있어야합니다. fsck가 있다면 항상 신뢰할 수있는 것은 아닙니다.
이것은 "우리가 오르막 길을 걸었다"는 이야기처럼 들리기 시작했다. 재부팅이나 셧다운과 같은 멋진 명령은 없었습니다. 시스템을 재부팅하려면 파일 시스템을 sync와 동기화 한 다음 콘솔에서 Ctrl-P를 눌러 중지합니다.
sync 명령이 종료되면 커널은 동기화를 예약했지만 모든 버퍼 (모든 중요한 파일 시스템 수퍼 블록 포함)가 반드시 디스크에 디스크를 만들지는 않았습니다. 따라서 동기화를 실행 한 다음 안전하기 전에 작업을 중단하는 것이 매우 쉽습니다.
동기화를 다시 실행하는 것은 쉬운 일이었고 시간이 걸리고 모든 것을 이해하지 않고도 직관적 인 호소력을 가졌거나 "count to 10"과 같은 모호한 명령을 처리하는 등의 일을했습니다.
V7 매뉴얼 페이지에는 BUG 섹션 update도 있습니다.
업데이트가 실행 중일 때 동기화가 실행될 때 CPU가 정지되면 파일 시스템이 손상 될 수 있습니다. 이는 부분적으로 NPR 요청이 실패 할 때 0을 기록하는 DEC 하드웨어 때문입니다. 해결 방법은 sync (1)가 시스템 실행 시간을 일시적으로 30 초 이상 증가시켜 업데이트 실행을 트리거하도록하는 것입니다. 이렇게하면 CPU가 30 초 동안 정지됩니다.
(V7 매뉴얼 1 권에서 가장 마지막이었습니다)
시간이 지남에 따라 파일 시스템 도구와 시스템 종료 및 재부팅을위한 프로그램이이를 처리하지 않도록 개선되었습니다. 시스템이 신비하게 행동 할 때 민속, 부두, 시스템 마법이 들어옵니다. 두 번 동기화하면 파일 시스템을 다시 연결하기 위해 비트 핀셋을 꺼내야 할 가능성이 훨씬 낮아 지므로 의식의 일부가되었습니다. 일단 여러 번 해본 후에는 생각하지 않고 해냅니다. 그런 다음 누군가가 알아 차리고 이유를 묻습니다. 그 대답은 "항상 그렇게 했어요. 더 안전합니다"와 같은 것입니다.
나는 이것이 권위 있다고 주장하지 않을 것이며, 일부 세부 사항에 대해서는 틀릴 수도 있습니다. 그러나 나는 그것이 기원에 아주 가깝다고 생각합니다.
sync; sync; sync; sync제목을 입력하는 동안 명확하게 설명 해야하며 때로는 입력하는 방식도 동일합니다. 동기화, 대기, 다시 동기화, 대기 등