問題タブ [ext3]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
svn - svn co が作成する .lock ファイルの数を減らしますか?
約 9K のディレクトリを含むディレクトリの Subversion 更新を行っています。これが保存されているファイルシステムには、4K をわずかに超える空き inode があります。svnclient が作成する .lock ファイルの inode が不足しているため、svn update の実行で問題が発生しています。
はい、消毒済みです。:) どうやら svn が大量の .lock ファイルを作成しているようです。問題は、リンク解除が十分に速く行われていないことだと思います.strace(strace -o /tmp/deleteme svn update
)で操作を遅くすると、別のディレクトリで更新が失敗するためです。スローダウンした strace がなければ、毎回まったく同じディレクトリで発生します。
今すぐこのファイルシステムのサイズを変更するのは不便です (当分の間、ext3 とこのサイズにする必要があります)。svn で作成する .lock ファイルを少なくする方法、または余分なファイルを作成する必要のない OS 提供の実際のファイル ロック機能を使用する方法はありますか? flock が NFS3 などで動作しないことは知っていますが、NFS ではチェックアウトしません。または、リンク解除を高速化するために使用できる ext3 チューナブルはありますか?
巧妙な回避策はありますか?「svn update ./*」を実行すると機能しますが、それには永遠に時間がかかります。というか、数十分。9K SSL 接続の作成については、作成よりも遅いと思います。:)
linux - dentry と i-node の数
試験で次の質問がありました。
ext3 ファイルシステムでは、dentry の数が i ノードの数よりも多くなります。
True または False で答えて説明する必要がありました。
私の答え:
dentry はディレクトリ間のリンクであり、基本的にすべてが i ノード (ディレクトリであっても) であるため、これは誤りです。
ただし、ext3 ファイル システムについては考慮していません。私が見逃したものはありますか、それとも私の答えは正しいですか?
linux - ext3 / ext4 ジャーナルへのアクセス
ext3 および ext4 ファイル システムにはジャーナリングがあります。ファイルに関する詳細やイベントを取得するための API がある可能性はありますか?
ユーザー空間プログラムがファイルのジャーナル項目にアクセスできるようにするある種の API。または、「ファイル x が削除されました」などのジャーナル イベントも。
これはある種のドキュメントのようですが、それが正しいものかどうかはわかりません。
java - プロデューサーからコンシューマーへの信頼性の高いファイルハンドオフ
次のように動作する2つの別個のJavaプロセス、プロデューサーとコンシューマーがあります。
プロデューサー:
消費者:
ハッシュファイルは、データファイルが完全であることを通知するためにこのコードでのみ使用されます。ハッシュの値はここでは検証されません。通常の負荷では、3秒ごとに1回のハンドオフが必要です。非常に重い負荷がかかると、レートは100ミリ秒ごとに1回のハンドオフに増加する可能性があります。ファイルシステムはext3で、data=orderedです。
消費者に不完全なファイルが表示されないようにするにはどうすればよいですか?
1つのオプションは、データファイルの内容をハッシュと照合することですが、これは不必要にコストがかかるようです。使用を検討しjava.nio.channels.FileLock
ましたが、プロデューサーがクラッシュした場合、ファイルがまだ不完全であってもOSがすべてのロックを解放するため、ハッシュチェックの必要性がなくなるのではないかと心配しています。これは実際には、不完全なファイルを作成する可能性が非常に高いケースです。たぶん、ロックに加えて、コンシューマーがまだ実行されていることを確認しますか?
embedded - 組み込みデバイスのext2/ext3
Linuxを使用せずに組み込みデバイスでext2またはext3ファイルシステムを使用できるようにしたいと思います。SATAハードドライブが接続された組み込みプロセッサを使用する予定です。Kernel.orgでソースコードを見つけましたが、使い方がわかりません。理想的には、ファイルの書き込み/読み取りなどのために呼び出すことができるいくつかの関数が欲しいです。これに関するドキュメントはありますか、または誰かが同様のことをしましたか。
ありがとう
ジョン
sqlite - B-Tree のノードはどのデータ構造を使用しますか?
Knuth の定義によると、次数 m (各ノードの子の最大数) の B ツリーは、次のプロパティを満たすツリーです。
(1) すべてのノードは最大で m 個の子を持ちます。
(2) すべてのノード (ルートを除く) には、少なくとも ⌈m⁄2⌉ の子があります。
(3) ルートがリーフ ノードでない場合、ルートには少なくとも 2 つの子があります。
(4) k 個の子を持つ非リーフ ノードには、k-1 個のキーが含まれます。
(5) すべての葉は同じレベルに現れ、情報を運ぶ。
出典:ウィキペディア
B ツリーのいくつかの視覚化は次のようになります。
この視覚化から、各ノードには配列データ構造 (または少なくとも同様のもの) があると思います。
その他は次のようになります。
これはリストのようなデータ構造のように見えます。
だから私の質問は:
Bツリーはどのデータ構造を使用しますか?
私のアルゴリズム クラスでの使用例は、データベースとファイル システムでした。SQLiteが B ツリー ノードを実装する方法を知っている人はいますか? またはext3?または、他の(よく知られている)実世界の例はありますか?
linux - 500GB のデータでタイプ ext3 のディスクをトラバースする方法
ディスク上には最大 1,000 万個のファイルがあります (同じディレクトリの下ではありません)。
すべてのファイルの [(file_name, file_size, file_atime)] を取得したい。しかし、コマンド
find /data -type f -printf "%p\t%A@\t%s\n"
絶望的に遅く、IO %util ~100% を引き起こします。
何かアドバイス?
linux - 多数のファイルを保存するための最適なディレクトリ構造
私たちが開発した 1 つのソフトウェアは、ますます多くのファイルを生成します。現在、1 日あたり約 70000 ファイル、それぞれ 3 ~ 5 MB です。これらのファイルは、ext3 ファイル システムの Linux サーバーに保存されます。ソフトウェアは毎日新しいディレクトリを作成し、その日に生成されたファイルをこのディレクトリに書き込みます。このような大量のファイルの書き込みと読み取りはますます遅くなっているため (つまり、ファイルごとに)、同僚の 1 人がサブディレクトリを1 時間ごとに開くことを提案しました。これによりシステムが高速になるかどうかをテストしますが、この問題は一般化できます。
ターゲットディレクトリ内のファイル数の関数として、ファイルの書き込みと読み取りの速度を測定した人はいますか? ファイルをサブディレクトリに配置する方が高速である最適なファイル数はありますか? 最適化に影響を与える重要なパラメータは何ですか?
前もって感謝します。
linux - 大量の小さなファイルをコピーするときに、NTFSファイルシステムがEXT3ファイルシステムと比較して非常に遅いのはなぜですか?
次のテストを実行しました。このバッチを使用して、400バイトの15'000ファイルを含むフォルダーを作成しました。
次に、次のコマンドを使用して、Windowsコンピューターにコピーして貼り付けます。
完了後、転送速度は915810バイト/秒であり、これは1MB/秒未満であることがわかります。7Mバイトをコピーするのに数秒かかりました。これは非常に遅いことに注意してください。
私は50Mバイトの単一ファイルを含むフォルダーで同じことを試しましたが、転送速度は1219512195バイト/秒です。(ええGB / s)瞬時。
なぜ多数のファイルをコピーするのに非常に時間がかかるのですか?Windowsファイルシステムのリソースですか?
ext3ファイルシステムを備えた仮想マシン(vmwareプレーヤー)の同じコンピューターで実行されるLinuxシステムで同じことを試みたことに注意してください。
cpコマンドを使用すると、コピーは瞬時に行われます。
次の点にも注意してください。
- ウイルス対策なし
- 複数のWindowsコンピューター(常にntfs)での動作をテストしましたが、常に同等の結果が得られます(7Mバイトをコピーするための転送速度は1MB/秒未満で平均7〜8秒)
- 私は複数のLinuxext3システムでテストしましたが、その量のコピーは常に瞬時に行われます(400バイトの15000ファイル)
- 問題は、たとえばLinuxのファイルシステムと比較して、Windowsファイルシステムが多数のファイルをコピーするのが非常に遅い理由を理解することです。