3

作成後すぐに削除される一時的なハード リンクまたはシンボリック リンクを数百から数千作成する必要があります。私の目的では、両方のタイプのリンクが機能します (つまり、ターゲットはディレクトリではなく、常に同じファイル システムに存在します)。

私が理解しているように、シンボリック リンクは元のファイルへのパスを含む小さなファイルを作成します。一方、ハードリンクは同じ inode 内のデータへの参照を作成します。したがって、これらのリンクを何千も作成/削除する場合は、何千もの小さなファイル (シンボリックリンク) またはこれらの参照 (ハードリンク) を何千も作成および削除する方がよいでしょうか? 1 つはハード ドライブ (おそらく断片化) に負担をかけ、もう 1 つはファイル システム自体に負担をかけるように見えますか? inode 参照はどこに保存されますか。あまりにも多くのハード リンクを作成すると、ファイル システムが破損する危険がありますか? 速度はどうですか？

あなたの専門知識をありがとう！

これは、ffmpeg を使用して、ディレクトリからの画像の任意のサブセットからムービーをエンコードできるようにするための回避策です。ffmpeg ではファイルに適切な名前を付ける必要があるため (frame%04d.jpg など)、ファイルのサブセットへのハード/シンボリック リンクを作成し、リンクに適切な名前を付けるだけでよいことに気付きました。これにより、元のファイルの名前を変更したり、実際にデータをコピーしたりする必要がなくなります。うまく機能しますが、何千ものリンクを繰り返し作成および削除する必要があります。

私が信じているこの問題にも対処します： ffmpegを使用して画像シーケンスを変換します

4

3 に答える 3

3

同じファイルに何十万も作成しようとしているわけではないので、ハード リンクの方がわずかにパフォーマンスが優れています。

ただし、/tmp が tmpfs の場合、/tmp 内のシンボリック リンクはさらに優れたパフォーマンスを発揮します。

ああ、シンボリックリンクは断片化の問題を引き起こすには小さすぎます。

于 2011-02-02T20:13:50.490 に答える
3

このアクティビティによってファイル システムが破損した場合、問題はファイル システムにあり、ユーザーにはありません。ファイル システムは一般に信頼性が高いため、心配する必要はありません。

どちらのオプションでも、ディレクトリにエントリを追加する必要があります。シンボリック リンクには、ファイルの作成も必要です。ファイルにアクセスすると、ハードリンクはコンテンツに直接ジャンプしますが、シンボリックリンクにアクセスするには、シンボリックリンクファイルを見つけて読み取り、コンテンツのあるディレクトリを見つけ、コンテンツの場所を見つけてからアクセスする必要があります。したがって、シンボリックリンクは、ファイルシステム全体でより多くの作業を行います。

しかし、ファイル内のデータを実際に読み取る作業と比較すると、違いはごくわずかです。したがって、私はそれについて心配することはなく、あなたが望むセマンティクスを最もよく提供するものを使用するだけです。

于 2011-02-02T20:16:43.233 に答える
2

どちらのオプションでも、ディレクトリiノードにファイルエントリを追加する必要があります。新しいブロックを割り当てると、ディレクトリ構造が大きくなる可能性があります。

ただし、シンボリックリンクにはiノードの割り当てが必要であり、ファイルシステムにはiノードの制限があります。数十万のシンボリックリンクがその制限に達する可能性があり、ギガバイトが空いている場合でも「ファイル用の十分なスペースがありません」というエラーメッセージが表示される場合があります。

デフォルトでは、ファイルシステム作成ツールは、物理パーティションサイズに応じてiノードの最大数を選択します。たとえば、Linux ext2 / 3/4の場合、で見つけることができる比率をmkfs.ext3使用します。bytes-per-inode/etc/mke2fs.conf

既存のファイルシステムの場合、iノードに関する情報を取得するコマンドは次のとおりです。

# dumpe2fs /dev/sda1 | grep -i inode | less

Inode count:              979200
Free inodes:              742304
Inodes per group:         16320
Inode blocks per group:   510
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       441066
Journal backup:           inode blocks

結論として、主にディスクとメモリ内のリソース消費（キャッシュ内のVFS構造）のためにハードリンクを優先する必要があります。

別のアドバイス：同じディレクトリにあまり多くのファイルを作成しないでください。パフォーマンスの問題を回避するには、2,000ファイルが妥当な制限です。

于 2011-11-06T17:47:17.680 に答える