ファイルのアップロードを処理する機能を構築するプログラミングでは、まずファイルを一時ディレクトリ/フォルダ (Linux では /tmp など) にアップロードするのが一般的な傾向のようです。ファイルのアップロードが完了すると、一時ディレクトリから移動され、指定されたディレクトリに保存されます。一部のプログラミング言語やスクリプト言語では、進行中のアップロードがデフォルトで /tmp に配置されますが、そうでない言語もあります。アップロードが完了するまで /tmp をプレースホルダー ディレクトリとして明示的に設定し、アップロードが完了した時点で別のディレクトリに移動するのが一般的な方法のようです。
ファイルを長期保存のために別のパーティション/ディレクトリに移動する前に、一時的な「保持」ディレクトリを使用してコンテンツをアップロードすることにはどのような利点がありますか?
私は、(社内の) ネットワーク ストレージが NFS マウントを介して仮想マシンにマウントされ、大量のデータ (テラバイト単位) を永続的に保存する環境で働いています。テクノロジが進歩するにつれて、より迅速に、より大量のデータを取り込むことができるようになりました。数年前は、一度に 1 つのファイル (比較的小さいサイズ、メガバイト単位?) を HTTP でアップロードするだけの単純な方法でしたが、その後 Flash アップロードに移行しました。現在ではドラッグ アンド ドロップによるアップロードが可能で、一部のブラウザーではギガバイト単位のファイル/フォルダー構造をアップロードできる可能性もあります。1 人のユーザーが一度に十分な量をアップロードしたい場合、/tmp 用に確保されているパーティションを簡単に超えてしまう可能性があります。NFS マウントによるネットワーク遅延以外に、/tmp を拡張することと、ファイル サーバーに直接送信することとを比較した場合の利点は何でしょうか。これは、テクノロジによって 10 年前には考えられなかった量のデータを取り込むことができるようになった現在では、時代遅れになった従来の (今では悪い) 習慣なのでしょうか。
答え1
- 指定したストレージディレクトリがネットワークストレージの場合のパフォーマンスのためでしょうか?
- はい、可能ですが、通常はそうではありません。実際のアップロードのパフォーマンスがコードの主なパフォーマンス上の懸念事項になることはほとんどありません。
- Linux は定期的に /tmp ディレクトリをスキャンして古いファイルを削除し、開発者や管理者が他の場所でそれを考慮する必要がなくなるのでしょうか?
- はい、通常はそうです。これは、アップロード マネージャー プロセスがクラッシュし、クリーンアップされない部分的なファイルが残ってしまうケースにも当てはまります。
- それはただそうなっているからそうなるのでしょうか？
- はい。 ：-）
- 最終的にファイルを保存するディレクトリにファイルを書き込む機会がある場合 (たとえば、node.js の fs モジュールを使用)、そうすべきでしょうか、それともそうすべきではないでしょうか?
- 一時ステージング ディレクトリを使用する理由と、それをターゲット ディレクトリと同じファイル システムに配置する理由には、十分な理由があります。多くのアプリケーションでは、このディレクトリを最終的なターゲット ディレクトリと同じファイル ツリーに配置するため、最終的な「移動」操作はほぼ瞬時に行われます (場合によってはアトミックになります)。そのため、 や のようなことがよく見られます
/var/spool/myapp/tmp。/var/spool/myapp/dataただし、アプリケーションでは、cron内の古いファイルをクリーンアップするタスクを追加することがよくあります.../tmp。
- 一時ステージング ディレクトリを使用する理由と、それをターゲット ディレクトリと同じファイル システムに配置する理由には、十分な理由があります。多くのアプリケーションでは、このディレクトリを最終的なターゲット ディレクトリと同じファイル ツリーに配置するため、最終的な「移動」操作はほぼ瞬時に行われます (場合によってはアトミックになります)。そのため、 や のようなことがよく見られます
答え2
これは、システム上に他に何があり、どのように使用されているかによって大きく異なります。
一部のシステムでは、システムファイルやスワップスペースとしてよく使用されます。Solarisで/tmpいっぱいになると、/tmp悪いことが起こる（および関連する逸話)。このような場合、誰かがこのボリュームをいっぱいにするファイルをアップロードすると、システムがクラッシュする可能性があります。また、特定のアプリケーションが独自の一時ファイルを書き込めなくなるなどの問題も発生する可能性があります。
昔は、人々が愚かなことをしない（少なくとも 9 月以外）と十分に信頼できましたし、悪意もかなり低かったです。今日では...それは別の話です。
のアドバンテージ書き込みの際の注意/tmp点は、マシン上のローカルファイルシステムであることが保証され、存在し、パトロールされていることです（スクリプトが巡回して古いファイルを自動的に削除します）。システム必要を起動し、これに高速にアクセスすること/tmpが、システムで適切なパフォーマンスを発揮するために必要でした。したがって、ファイルをどこかにすばやく書き込み、それを移動したいですか? それを に入れます/tmp。
いっぱいになると悪いことが起こるという点については/tmp、同じ利点を提供する他の代替案を検討する必要があります。たとえば、いっぱいになったときにマシンがクラッシュしないように、ファイルをアップロードするためにマウントされるパーティションを作成するなどです。
もう一つの考慮すべき点は「高速」という点です。ドライブは昔に比べて高速化しています。かなり高速化しています。優れたSSDは当時のものよりはるかに高速です...しかし、本当にアップロード ファイルの書き込みに SSD が必要ですか? ダイビングが高速になっただけでなく、ネットワークも高速になりました。アップロード ファイルをネットワーク ストレージ領域に書き込むと、複数のシステムがファイルを中央の場所にアップロードできる単一のポイントが実現し、他のプロセスがファイルをスキャンして適切な場所に移動する責任を引き受けることができます。
ということで、要約すると次のようになります。
- 昔は有利だった
- ネットワークよりも速く、いつでも利用可能
- 問題を引き起こす可能性がある
- 昔の日々はもうここにはない
- ドライブとネットワークの高速化
- 人々は愚かで攻撃者が多い
したがって、デフォルトの回答としては、これ以上書き込まないでください/tmp。システム管理者に問い合わせて、ディスク使用ポリシーに適合する適切な書き込み場所を確認し、ローカル システムから完全に離れた場所に書き込むことを検討してください。
答え3
/tmpは、単にファイルを置くのに便利な場所であり、クリーンアップされることがほぼ確実である場所です (たとえば、Web アプリがクリーンアップに失敗した場合など)。したがって、これは妥当なデフォルトです。
ファイルをアップロードするための独自のパスを指定するオプションがある場合は、最終的な宛先と同じマウント上のパスにすると、アトミックな名前変更を使用して最終的な場所に配置できるため、十分な理由があります。(クロスマウントの場合は、コピーを行う必要があります)。
最終的な宛先にアップロードすることはお勧めしません。たとえば、アップロードが途中で中止された場合、不完全なファイルがそこに残ってしまう可能性があります。または、スクリプトが停止した場合、データベースによって参照されない孤立したファイルが残ってしまう可能性があります。
ところで、クライアントから提供されるファイル名は信頼できないデータであることに注意してください。悪意のあるユーザーが簡単にファイル名を渡す可能性があり../../../something、注意しないと意図しない場所に書き込んでしまう可能性があります。