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つのキーを押すのが難しいことを意味します。望むものではありません。 ）、できるだけ多くのデータがディスクに書き込まれるため、次回の起動時にfsckは必要なく、データ損失のリスクを最小限に抑えるより良いシャットダウン方法です。
SysRqの組み合わせの完全なリストといくつかのニーモニックを含む多くの情報があります。Magic SysRqのウィキペディアページ。
答え2
具体的な内容は何ですか？この場合、LinuxはMS-Windowsよりも弾力性がありませんか？
ある時点で比較が役に立ちます。この比較により、これらのSysRQコマンドがよく知られている理由を説明できます。しかし、最新のLinuxとWindowsのバージョンを比較することはうまくいきません。
「ジャーナリングファイルシステム」が何を意味するのかを理解している場合は、詳細についてはほとんど説明します。 例を参照。
この参考資料によると、人気のあるLinuxファイルシステムファミリは、Microsoftよりも遅くジャーナリングファイルシステムのサポートを受けています。
また、一般的な理解は、Linuxファイルシステムがまだかなりうまく修復できることですfsck。問題は、fsckより大きなディスクでは時間がかかるため、ロギングがより最適化されることです。
最新の大規模ディスクでこれを行うのにかかる時間を考慮すると、ロギングがさらに「復元力」が高まったことは間違いありません。 :-).原則として、同期は、ジャーナリングファイルシステムに関係なく、いくつかの用途に使用することもできる。これにより、同期されていないファイルの内容を含む即時書き込み保存をトリガーできます。 （その後、書き込みの保存が完了した時点を推測するには、ディスクLEDまたはノイズを観察する必要があります。）たとえば、dirty_writeback_centisecsこれによりextファイルシステムを待つ必要はありません。一部の人はシステムを構成して使用する人もいます。「ノートブックモード」怠惰な書き込みストレージは、電力を節約するために無期限に遅延されます。
1つの追加の詳細があります。 Linuxのジャーナリングファイルシステムは、barriers無効な状態で実行されないと仮定する傾向があります。障壁がパフォーマンスに与える影響が軽減され、Linuxディストリビューションではデフォルトで障壁の無効化が停止しました。 （または、特定の状況や一部のハードウェアでは、障壁を無効にすることが「安全」である可能性がありますが、これは2018年現在の一般的なPCハードウェアには適用されません。例を参照。
引用符（一部の形式 - 便利なリンク - 欠落している）：
ジャーナルファイルシステム
ファイルやディレクトリの変更を反映するようにファイルシステムを更新するには、別の書き込み操作が必要なことがよくあります。これにより、書き込み間の中断（停電やシステムクラッシュなど）が発生し、データ構造が無効な中間状態になる可能性があります。 [1]
たとえば、Unixファイルシステムからファイルを削除するには、次の3つの手順が必要です。 [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オプションは、仮想マシンで構成されているストレージと一緒に使用しないでください。