web-dev-qa-db-ja.com

/ varでシンボリックリンクしても安全なものは何ですか?

別のマウントされたデバイスに十分なスペースがあります。/varパーティションはサイズの点で比較的静的なままなので(大きなログが必要なため、約8〜10 GB)、現在の/ varスペースを75%ではなく65%にするだけでかなり満足しています。言い換えれば、私たちはあまり移動する必要はありません。これが現在そこにあるもののスナップショットです:

4.0K ./account
119M ./cache
0./clamd
292M ./cpanel
8.0K ./crash
12M ./ csectsh 
 528M ./data
16K ./db
16K ./empty
6.1G./lib
4.0K ./local 
 24K ./lock
1003M ./log
16K./lost+found
0./mail
120K./named
 4.0K ./nis
4.0K ./opt
8.0K ./portsentry
20M ./pravda
4.0K./preserve
84K ./profiles
236K ./run
115M ./spool
470M ./tmp
4.0K ./yp

本番サーバーで大量のデータを再パーティション化したばかりなので、特にクライアントとのSLA)があると信じているので、ダウンタイムを増やす予定はあまりありません。これらのファイルの親プロセスにはシンボリックリンクの問題がありますが、これは継承されたシステムであるため、専門家にはほど遠いです。移動できるものに対する確実な賭けを知っている人はいますか?

2

強くは、シンボリックリンクではなく、代わりにバインドマウントを使用することをお勧めします。

こうすることで、シンボリックリンクのようにウィッシュウォッシュになるのではなく、スペースを明確に追跡できます。

http://aplawrence.com/Linux/mount_bind.html マウントをバインドするための優れたイントロがあります。

3
warren

おそらく/ var/libにMySQLがあります-それを別のマウントに移動するか、新しいディスクをセットアップしてください。シンボリックリンクするか、MySQL構成を変更できます。

2
pauska

./dataには何が含まれていますか?これは標準のディレクトリではなく、適切な候補のように見えます。また、./libをさらに深く掘り下げることをお勧めします。そこにある何かが多くのスペースを占めており、削除または移動のために使用されている可能性があります。

1
Zoredache