- ベストアンサー
/usr/share/docの移動とシステムへの影響
- RH9をインストールした後、dfコマンドでディスク領域の使用率が100%になっていることが判明しました。
- /usr/share/docディレクトリが573MB占めていることが分かりました。
- このディレクトリをfat32のHDD下に移動してリンクを張ることでシステムの運用に問題は生じないでしょうか。
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
> ファイルロックをかけているプロセスを特定する方法はあるのでしょうか? う～ん、ツールを使わんのやったら、/proc/数字/fd/の中にあるシンボリックリンクを1個1個見ていけば良い(かなり力技)と思うけど、めんどいしツールを使おう。 lsofやfstatで検索するよろし。2つともVineには標準で入ってない。他のディストリビューションは分からんです。
その他の回答 (2)
- anmochi
- ベストアンサー率65% (1332/2045)
> セキュリティ関連でパーミッション等にやかましいプログラム類が沢山あると思うのですが、、、 ああ、うん、つまり、どうせパーミッションの設定ができなくなっても(誰でもアクセス、実行できるようになっても)、個人使用なら別にええやんって事。例えば~/.ssh/authorized_keysなどはどうするっちゅう話やったら、擬似的にパーミッションを変更する仕組みもある。 > ・・・・となっていました(ガクーンと使用率が減ってます(喜))。 この間にシステムのリブートはあったのだろうか？ その場合は、プロセスがロックをかけているファイルの解放が行われたからだ。例えば、ログのようにあるプロセスがあるファイルを書き込みでオープンしていたら、そのファイルを移動や削除をしたとしてもプロセスをKILLしないとinodeもファイル使用中のラベルもずっと残っているのだね。ext2、ext3の話でfatではどうなるか分からんけど・・・・。
補足
有難うございます。 >> セキュリティ関連でパーミッション等にやかましいプログラム類が沢山あると思う > のですが、、、 > ああ、うん、つまり、どうせパーミッションの設定ができなくなっても(誰でもアク > セス、実行できるようになっても)、個人使用なら別にええやんって事。例えば > ~/.ssh/authorized_keysなどはどうするっちゅう話やったら、擬似的にパーミッショ > ンを変更する仕組みもある。 ~./qmail とか ~/.fetchmailrc とかってパーミッションが600とかしとかないと起動出来なかったじゃないですかね。 sshって設定ファイルが777とかでも使えるんですね。 知りませんでした。 >> ・・・・となっていました(ガクーンと使用率が減ってます(喜))。 > この間にシステムのリブートはあったのだろうか？ いえ、全くリブートしてません。 ディスク領域が100%になっていたので、もしかしてブートできなくなるのでは。と心配で、リブートを踏みとどまってました。 > その場合は、プロセスがロック > をかけているファイルの解放が行われたからだ。例えば、ログのようにあるプロセス > があるファイルを書き込みでオープンしていたら、そのファイルを移動や削除をした > としてもプロセスをKILLしないとinodeもファイル使用中のラベルもずっと残ってい > るのだね。ext2、ext3の話でfatではどうなるか分からんけど・・・・。 dfコマンドはプロセスが関係しているのですね。 とても参考になります。 覚えておきます。 ディスク領域がdfコマンドで100%と表示されたから必ずしも100%担っていない場合もあるわけですね。、開放が行われていないだけかもしれないのですね。 ところで ファイルロックをかけているプロセスを特定する方法はあるのでしょうか?
- anmochi
- ベストアンサー率65% (1332/2045)
とりあえず個人使用のOSやし（fatに置いても）特に害はないと思うよ。 正味の話、ハードディスクから起動する場合のLiunxにおいては/etc以外はどこに置いても差し支えない。なので、どうでも良いやと思うものはばっさりやってしまおう(rmじゃなくてmvとlnね)。
お礼
経過報告です。 /usr/share/doc下ファイルはただのドキュメントファイル類でfat32領域に置くと皆 に見られるようになるだけで特にシステムの動作には問題はないのですよね。 でもパーミッションとかに多少変化があるのは嫌なのでとりあえず、 # cd /home/user01/fat32 # dd if=/dev/zero of=doc.ext2 bs=1024k count=573 # mke2fs -F doc.ext2 # mv /usr/share/doc /usr/share/doc.org # mkdir /usr/share/doc # mount -o loop doc.ext2 /usr/share/doc # cp -R /usr/share/doc.org/* /usr/share/doc/ # rm -fr /usr/shar/doc.org としまってました(でも、3%くらいしか空き領域を確保できませんでした。しかも時 間でまた100%に達してしまいました) 前もって、 # /sbin/tune2fs -j /home/user01 /fat32/doc.ext2 としといた方がいいんですかね。 でもでも不思議な事が発生しました。 今日起きて、dfみましたら、あれれ～!!!!! # df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda1 9250496 5587920 3192676 64% / となっていました(ガクーンと使用率が減ってます(喜))。 duコマンドで/下のディレクトリサイズを見てみましたが特に変化が有りませんでし た(なんでこんなに減ったの!?)。 よくよく考えてみると、昨日duコマンドで測定した各ディレクトリサイズを単純に各 ディレクトリサイズの合計から100%になる筈はなかったのです。。。 なのに 昨日は100%に達していて、/usr/share/docをhda1から移動して、/var/log下のログ ファイルを殆ど削除したにも拘らず、一時的に空きスペースは出来ましたが直ぐに 100%に達していました。 つまり、昨日はdfの表示がおかしくて、今日のdfコマンドは正常に出力しているよう です。 まさか、Linuxがdfが誤作動を起こして計算を誤ってたなんて不思議な現象ってある のでしょうか????
補足
有難うございます。 > とりあえず個人使用のOSやし（fatに置いても）特に害はないと思うよ。 本当ですか??? セキュリティ関連でパーミッション等にやかましいプログラム類が沢山あると思うのですが、、、 /usr/share/docならただ閲覧するだけなので問題無いだろうと思いました。
お礼
>> ファイルロックをかけているプロセスを特定する方法はあるのでしょうか? > う～ん、ツールを使わんのやったら、/proc/数字/fd/の中にあるシンボリックリン > クを1個1個見ていけば良い(かなり力技)と思うけど、めんどいしツールを使おう。 > lsofやfstatで検索するよろし。2つともVineには標準で入ってない。他のディスト > リビューションは分からんです。 有難うございます。 参考にしてみます。