同期すべき哲学に真実はありますか。同期;同期;同期しますか？
2000年にシスコに勤務してLinuxを初めて紹介されたとき、ファイルシステムの破損やデータの損失を防ぐためにバッファをディスクにフラッシュするために使用されるsyncコマンドのメリットを教えられました。同僚だけでなく、大学の友人からも、syncを「一度」ではなく、「数回」または「数回」、つまり5〜10回実行するように言われました。
それ以来、この習慣を続けてきましたが、何かメリットはありますか？これを聞いた人はいますか？そして最も重要なこととして、誰かがsyncを効果的に実行するために2回以上実行する必要があるという考えに対して/に対して良い根拠/経験的証拠を提供できますか？
syncコマンドを3回入力すると（申し訳ありませんが、どこで忘れたか）聞いたことがあります（例： SYNCReturn、プロンプトを待つ、繰り返す、繰り返す）。また、Originは、オペレーティングシステムにすべてが正常であると通知した後でも、ディスクがバッファーのフラッシュを完了するまでに数秒かかる特定のシステムであることも読みました。コマンドをさらに2回入力すると、ディスクが安定するのに十分な時間が与えられました。何年もの間、目的は忘れられ、アドバイスはsync; sync; syncと省略されましたが、これは望ましい効果をもたらしませんでした（ディスクが「すべてクリア」を報告していたため、2番目と3番目の同期は即座に完了し、プロンプトが早く戻りすぎます）。
複数のsync操作が使用されるシステムについて聞いたことがなく、存在するものについては非常に懐疑的です。これは都市伝説だと思います。その一方で、同期してから電源を切るまでに数秒待つ必要があるシステムがあると確信しています。
グーグルは、いくつかの独立した同時分析につながります。 伝説の同期 。 linuxをシャットダウンする前にsync（8）を実行する必要があるか？ も参照してください。
ここでオールドタイマー。 TAPEの栄光の時代に戻って、3つの高速同期は、TAPEコントローラーにテープストリームのリンクを解除/スプール解除するだけでなく、それを巻き戻すように、つまりFD/rw-headを設定するように指示する方法でした0に。
"sync; sync; sync"は、TAPEベースのUnix、つまり、当時最も安価なストレージである/ var/spoolにファイルがマウントされたアプリを試してみた人たちだけが実際に生産的に使用していました。 ;）
MIPS Risc/OSオペレーターマニュアルには、このページがあります。
「sync; sync; sync」のように1つのコマンドラインですべてを同期するのではなく、複数回同期するほうが安全な古いUNIXシステムは確かにありました。 80年代半ば、これは次のように蒸留されました。
システムをシャットダウンすると、3回同期する必要があります。それ以上でもそれ以下でもありません。同期数は３つ、同期数は３つとする。 4回目の同期は行わないでください。2回目の同期は行わないでください。ただし、3回目の同期に進む場合を除きます。
３回はどこから来たのか本当にわからないけど、たぶん楽しかった。しかし、路上での言葉はそれを2回行う。 「同期;同期」ではなく、シェルの2つの別々の行として。
たとえば、V7 UNIXの時代には、ファイルシステムの修復はそれほど楽しくありませんでした。ファイルシステムがどのように機能するか、およびdcheck、ncheck、icheckなどのプログラムの特異性について多くのことを理解して、手動で行う必要がありました。 fsckがあったとしても、信頼できるものとは限りませんでした。
これは「雪の上り坂を双方向に歩いた」という話のように聞こえ始めています。まあ、リブートやシャットダウンのような特別なコマンドはありませんでした。システムを再起動したいときは、ファイルシステムを同期で同期し、コンソールでCtrl-Pを押して停止しました。
Syncコマンドが終了したとき、カーネルは同期をスケジュールしていましたが、すべてのバッファー（すべての重要なファイルシステムスーパーブロックを含む）が必ずしもディスクに到達したわけではありませんでした。したがって、同期を実行し、安全になる前に停止するのは非常に簡単でした。
もう一度同期を実行するのは簡単で、時間がかかり、すべてを理解したり、「count to 10」などのあいまいな指示を処理したりする必要がなく、直感的な魅力がありました。
V7のmanページにupdateのBUGセクションもありました：
更新が実行されている場合、同期が実行された直後にCPUが停止すると、ファイルシステムが損傷する可能性があります。これは、NPR要求が失敗したときにゼロを書き込むDECハードウェアが原因の一部です。修正は、sync（1）が一時的にシステム時間を少なくとも30秒増やして、更新の実行をトリガーすることです。これにより、30秒の猶予が与えられ、CPUが停止します。
（ちなみに、これはV7マニュアルの第1巻の最後の部分でした）
時間の経過とともに、システムのシャットダウンと再起動のためのファイルシステムツールとプログラムは、これに対処することを回避するために改善されました。システムが不思議なふるまいをするとき、民俗学、ブードゥー教、そしてシステム魔法がそれに入ります。 2回同期すると、ファイルシステムを元に戻すためにビットピンセットを外す必要がほとんどなくなるため、儀式の一部になりました。何度もやったら、何も考えずにやります。その後、誰かがそれに気づき、その理由を尋ねます。そして、答えは「常にそのようにしてください。それはより安全です」のようなものです。
私はこれが信頼できると主張するつもりはありません、そして私はいくつかの詳細について間違っているかもしれません。しかし、それは起源にかなり近いと思います。