タグ付けされた質問 「journaling」

WindowsにはEverythingという素晴らしいファイル検索エンジンがあります。これは（とは異なりfind）非常に高速で、（とは異なりlocate）常に最新の結果を返します。私の知る限り、NTFSジャーナルからデータベースを埋めることで機能します（他のファイルシステムでは機能しません）。 Linux（ext3またはext4）に似たようなもの（GUIについては気にしません。私のポイントは速度と最新の保証です）があるのでしょうか。Googleで検索しましたが、何も見つかりませんでした。このようなことはできますか、誰かがそれに取り組んでいますか？

46 filesystems  search  journaling 

古典的な状況：私は悪い実行し、rmすぐに間違ったファイルを削除したことを実現しました。（重要なことは何もありませんでしたが、最近のバックアップは許容範囲内でしたが、まだ迷惑です。） extundeleteまたはそのようなツールを使用してファイルを回復したい場合、さらなるディスクアクティビティが敵であることがわかったので、すぐに物理的にマシンの電源を切りました（つまり、haltコマンドではなく、電源ボタンで）。これは重要なタスクが実行されていない、または何も開いていないラップトップであるため、許容できる操作でした。（ところで、そのような状況で最初にすることは、プロセスhttps://unix.stackexchange.com/a/101247によって見つからないファイルがまだ開かれている可能性がある場合、最初に推定することであることをその後学びました-存在する場合、マシンの電源を切るのではなく、この方法で回復する必要があります。） それでも、マシンの電源を切った後、しばらく考えて、ファイルが適切なフォレンジックのためにライブシステムを起動する時間投資に見合わないと判断しました。そこで、マシンの電源を入れました。そして、ファイルがまだディスクに残っていることを発見しましrmた。電源を切る前にファイルがディスクに伝播されていませんでした。私は少しダンスをし、システム管理者の神に彼の予期せぬ許しに感謝しました。 私の質問は、これがどのように可能だったか、そしてrm実際にディスクに伝播されるまでの典型的な遅延とは何かを理解することです。ディスクIOはすぐにはフラッシュされず、しばらくの間メモリ内に置かれることはわかっていますが、ディスクジャーナルにより、保留中の操作が完全に失われないようにすばやく確認できると考えました。https://unix.stackexchange.com/a/78766は、ダーティページをフラッシュし、ジャーナル操作をフラッシュする別のメカニズムを示唆しているように見えますが、ジャーナルがa rmにどのように関与するかについての十分な詳細と、操作がフラッシュされます。 いくつかの詳細：データはLUKSボリューム内のext4パーティションにあり、マシンを起動してバックアップしたとき、次のことがわかりましたsyslog： Sep 24 10:24:58 gamma kernel: [ 11.457007] EXT4-fs (dm-0): 1 orphan inode deleted Sep 24 10:24:58 gamma kernel: [ 11.458393] EXT4-fs (dm-0): recovery complete Sep 24 10:24:58 gamma kernel: [ 11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) しかし、私はそれがに関連していると確信していませんrm。 別の質問は、マシンの電源を落とすのではなく、保留中のディスク操作を実行しないようにカーネルに指示する方法があるかどうかです（ただし、どこかにダンプするなど）。（もちろん、保留中の操作を実行しないのは危険に思えますが、これはとにかくマシンの電源を切ったときに起こることであり、場合によってはそれがあなたを救う可能性があります。）たとえば、物理的な電源切断が簡単なオプションではないリモートサーバーの場合。

31 linux-kernel  data-recovery  rm  virtual-memory  journaling 

Ubuntuチャットルームで問題を提起した別のユーザーに代わってこの質問をしています。 ジャーナリングファイルシステムは、電源障害が発生した場合に破損が発生しないことを保証していますか？ この回答がファイルシステムに依存する場合、どのシステムが破損を防止し、どのシステムが保護しないかを示してください。

28 filesystems  journaling  corruption 

ルートファイルシステムにinitramfsを使用し、コンパクトフラッシュIDEドライブにマウントされたカスタムext3パーティションを使用する組み込みセットアップがあります。電力損失に直面した場合のデータの整合性は、セットアップ全体で最も重要な要素であるため、次のオプションを使用してマウントしました（以下は/etc/fstabファイルのエントリです） <file system> <mount pt> <type> <options> <dump><pass> /dev/sda2 /data ext3 auto,exec,relatime,sync,barrier=1 0 2 これらのオプションは、インターネットで読み回して得たものです。私が心配しているのは/proc/mounts、次の内容を提供することです。 /dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl, barrier=1,data=writeback 0 0 私が読んで理解していることからdata=journal、マウントにオプションを使用したいということは、これがデータ破損に対する最高の保護を提供するからです。ただし、特定のext3オプションのマニュアルページにはmount、ライトバックオプションについて次のように記載されています。 データの順序は保持されません-メタデータがジャーナルにコミットされた後、データはメインファイルシステムに書き込まれます。 これは、最高のスループットオプションであると噂されています。内部ファイルシステムの整合性を保証しますが、クラッシュおよびジャーナルの回復後に古いデータをファイルに表示できるようにします。 私はこれについて非常に混乱しています-ファイルシステムの整合性のためにdata=writebackオプションを指定したいことをmanページが示唆しているようですmountが、私が見つけた他のほとんどの参考文献（組み込みLinuxに関する出版された本を含む）は私が使用すべきだと示唆していdata=journalます。私にとって最適なアプローチは何ですか？書き込み速度はまったく問題ではありませんが、データの整合性は重要です。

15 mount  ext3  journaling