- ベストアンサー
ディスク容量がいっぱいになってしまいました。。。
皆様よりご教授賜りたく宜しくお願い致します。 1.SQLを実行すると、以下のERRORが出てしまいました。 ltsWriteBlock: failed to write block 1471 of temporary file Perhaps out of disk space? 2.ディスクの容量を確認すると以下のようになり./dev/hda2が、使用100%なので、 ------------- Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda2 7052496 6682468 11780 100% / ------------- 3./配下のディレクトリ容量を見てみると ---------------------------------------------------------------- drwxr-xr-x 2 root root 4096 5月 27 2004 bin drwxr-xr-x 4 root root 1024 5月 27 2004 boot drwxr-xr-x 20 root root 118784 7月 5 12:11 dev drwxr-xr-x 58 root root 4096 7月 5 12:07 etc drwxr-xr-x 7 root root 4096 5月 27 2004 home -以下省略--------------------------------------------------------- 4.なのでサイズの一番大きい/devを確認してみると -抜粋-------------------------------------------------------------- brw-rw---- 1 root disk 13, 121 8月 31 2002 xdb57 brw-rw---- 1 root disk 13, 122 8月 31 2002 xdb58 brw-rw---- 1 root disk 13, 123 8月 31 2002 xdb59 brw-rw---- 1 root disk 13, 70 8月 31 2002 xdb6 brw-rw---- 1 root disk 13, 124 8月 31 2002 xdb60 brw-rw---- 1 root disk 13, 125 8月 31 2002 xdb61 ----------------------------------------------------------------- 5.この中身は削除してしまって良いものでしょうか??? ■環境 OS:RedhatLinux Workstation
- みんなの回答 (6)
- 専門家の回答
質問者が選んだベストアンサー
こんにちは。またまた御邪魔します。 使用量が78%になれば、とりあえず使える状態ですね。 Linux の場合は、ls -la コマンドと du -sm コマンドを組み合わせて、容量を大きく消費しているディレクトリを探していくという感じですね。 あと、今ごろのご案内で申し訳ありませんが、find コマンドも便利です。 # find / -size 10000k -print とやると、10Mバイト以上のファイルをリストアップしてくれます(ディスク全体を探すので時間はかかりますが)。 -print の代わりに -ls とすると詳細情報を表示してくれます。 find コマンドでサイズの大きいファイルを探せば、効率良く空き領域を確保できるんじゃないかと思います。 あと、ディレクトリエントリを管理する領域の使用量ですけど、一度確保されてしまった領域は、そのディレクトリの中のファイルを削除しても解放されない(ファイル名リストに削除マークがつく)ので、ディレクトリエントリの消費サイズは減らないんです。 現状で、 /dev ディレクトリを管理するために 118784 バイト使われているわけですが、仮に /dev の中のファイルを消しても 118784 というサイズは変わりません。 rmdir /dev してから mkdir /dev すると、初期状態の 1024 バイトになるというわけです。 ちなみに /dev の中のファイルはLinuxにとって重要なものばかりなので、消さないようにしましょう。
その他の回答 (5)
- haru44
- ベストアンサー率60% (12/20)
こんにちは。再び御邪魔します。 これまでの経緯で、du -sm で調べていないディレクトリは下記の5つということになったと思います。#2 さんは /tmp を外して、とおっしゃっていますが /tmp を除外する意味はないと思いますので、/tmp も含めて下記のディレクトリの # du -sm の結果を調べてみていただけませんでしょうか。 drwxr-x--- 13 root root 4096 7月 6 17:49 root drwxr-xr-x 2 root root 8192 5月 27 2004 sbin drwxr-xr-x 3 root root 4096 5月 27 2004 tftpboot drwxrwxrwt 7 root root 12288 7月 7 09:56 tmp drwxr-xr-x 15 root root 4096 5月 27 2004 usr /tmp の日付が新しくなっていますので、/tmp の中にファイルを作るプログラムが活発に動いている(使われている)のかもしれませんね。 ls コマンドで表示させると、.(ピリオド)で始まるファイルは表示されませんので、ぜひ # du -sm /tmp などとして調査をお願いします。 あと、ls コマンドに -a をつけると、ピリオドで始まるファイルも表示してくれますので、 # ls -la /tmp の結果も見たいです。 ところでディレクトリエントリが消費する容量の話ですが、ファイルシステムの内部には、ディレクトリの中に入っているファイルを管理する領域があり、普通のファイルと同じようにディスク領域を消費します。 Windows系(DOS系)のシステムではどのくらい消費しているのかの表示はありません。Windows では空欄で表示されますが、容量を消費しないのではなく、表示していないだけなんですね。 これが、Linux などの UNIX 系のファイルシステムでは、ディレクトリ情報を格納するために何バイト消費しているかが正確に表示されます。 ディレクトリ内のファイル数が少なければ、ブロック数は少なくて済むので最小1ブロック(1024バイトなど)になります。ファイルが増えてきて1ブロックに収まらなくなると、2048バイト、3072バイト、4096バイト…、という具合に増えていきます。 /dev ディレクトリの管理情報が118784バイトということは、ファイル数が膨大であることを示しているといえます。ちなみに拡張された管理領域は、ファイルを消しても小さくなりません。どうしても小さくしたければ、ディレクトリを作り直せば初期状態に戻ります。 ls コマンドが表示するのはディレクトリ管理情報のサイズなので、実際に格納されているファイルサイズとは関係がありません。そこで、du コマンドを使います。du -sm コマンドは、ディレクトリの中のファイルを(再帰的に)ひとつずつ調べて総容量を調べています(だから少し時間がかかります)。 Windows の場合、du コマンドに相当するのは、フォルダを右クリックして「プロパティ」ですね。
お礼
細かくご説明頂きありがとうございました!! なるほど・・・。個々のファイルサイズが小さくてもファイルが増えれば増える程入れ物(ブロック)が必要になるということですね。 一度、広げた入れ物は小さくならない。小さくならないけれども、ファイルが減れば、中は空になっているっということで、使用量は、当然減るのですよね? >/tmp も含めて下記のディレクトリの ># du -sm >の結果を調べてみていただけませんでしょうか。 実行してみました。 # du -sm /root 8 /root # du -sm /sbin 12 /sbin # du -sm /tftpboot 1 /tftpboot # du -sm /tmp 1 /tmp # du -sm /usr 4928 /usr このような結果です。また、 >あと、ls コマンドに -a をつけると、ピリオドで始まるファイルも表示して>くれますので、 ># ls -la /tmp >の結果も見たいです。 こちらは # ls -a /tmp . .X11-unix .gdm_socket .s.PGSQL.5432 sess_29adb6b3296cae9559317c2db2a7a001 .. .fam_socket .iroha_unix .s.PGSQL.5432.lock sess_6212c44d6822b5ab579b965b1122e212 .X0-lock .font-unix .ki2-unix orbit-root sess_80c5d34c2c53d838ea5c9a8b827fcdfd でした。 それから、いろいろ試行錯誤しOSインストール時に入れた未使用なサービスを 消したり、以下のディレクトリで不要なものがあったので削除したりして、今は以下まで空きました。 削除したディレクトリ /usr/local/apache/htdocs/配下のディレクトリ Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda2 7052496 5161408 1532840 78% / /dev/hda1 497829 13492 458635 3% /boot /dev/hda3 4032124 311772 3515524 9% /home none 126696 0 126696 0% /dev/shm /dev/hda5 3020140 248080 2618644 9% /var
- haru44
- ベストアンサー率60% (12/20)
drwxr-xr-x 20 root root 118784 7月 5 12:11 dev の 118784 は、/dev 以下のファイルの総使用量ではなくて、/dev というディレクトリエントリ自身が消費しているブロック数なので、ls -l の結果を見て /dev が一番大きいと判断するのは短絡過ぎですね。 #2さん、#3さんも指摘している du -sm の出力で判断するのが一番良いのですが、#3 の書き込みを見ると / 直下のファイルもクサイですね。 # ls -l / の結果はどうでしょうか。
お礼
返事が遅くなり済みません。ご回答ありがとうございます。 ># ls -l / >の結果はどうでしょうか。 早速実行してみました。このような結果です。 合計 205 drwxr-xr-x 2 root root 4096 7月 5 17:30 bin drwxr-xr-x 4 root root 1024 5月 27 2004 boot drwxr-xr-x 20 root root 118784 7月 7 09:56 dev drwxr-xr-x 56 root root 4096 7月 7 09:56 etc drwxr-xr-x 7 root root 4096 5月 27 2004 home drwxr-xr-x 2 root root 4096 6月 22 2001 initrd drwxr-xr-x 7 root root 4096 5月 27 2004 lib drwx------ 2 root root 16384 5月 27 2004 lost+found drwxr-xr-x 2 root root 4096 8月 27 2002 misc drwxr-xr-x 4 root root 4096 5月 27 2004 mnt drwxr-xr-x 2 root root 4096 8月 24 1999 opt dr-xr-xr-x 67 root root 0 7月 7 2005 proc drwxr-x--- 13 root root 4096 7月 6 17:49 root drwxr-xr-x 2 root root 8192 5月 27 2004 sbin drwxr-xr-x 3 root root 4096 5月 27 2004 tftpboot drwxrwxrwt 7 root root 12288 7月 7 09:56 tmp drwxr-xr-x 15 root root 4096 5月 27 2004 usr drwxr-xr-x 23 root root 4096 7月 6 11:30 var また、 >drwxr-xr-x 20 root root 118784 7月 5 12:11 dev >の 118784 は、/dev 以下のファイルの総使用量ではなくて、/dev というディレクトリエントリ自身が消費しているブロック数なので、ls -l の結果を見て /dev が一番大きいと判断するのは短絡過ぎですね。 LINUXはほとんどさわったことが無く、Windowsのディレクトリの概念と少し異なるようで、戸惑っています。。。 ここで指摘されている >消費しているブロック数 とは、使用量とは違うのでしょうか?
- zem
- ベストアンサー率70% (51/72)
/ 配下ですよね、もしかして「/」ディレクトリ内に大きな core ファイルや一時ファイルが作成されていませんでしょうか。「/tmp」にも大きなファイルがあるかもしれません。
お礼
「/」ディレクトリには、フォルダしかないようです。 「/tmp」にも、特別大きなファイルはありませんでした。。。 ちなみに、du -sm ではサブディレクトリ内の容量も合計して算出されているのでしょうか???
- tropic_snow
- ベストアンサー率61% (51/83)
/(ルート)と/homeは別パーティションだったんですね。 だとすると、先程の > おそらく、/home/の下がいっぱいなんじゃないですか? は、間違いです。すみません。 さて、だとすると、どこが一杯になってるんでしょうね?/boot,/home,/varは別なので、それ以外を地道に見ていくしかないかも。あ、/procと/tmpも外してくださいね。 # du -sm /misc # du -sm /opt # du -sm /root : という感じで…。
お礼
>/(ルート)と/homeは別パーティションだったんですね。 >だとすると、先程の すみません。文字数の関係で情報が全て載せられなかったもので・・・。 一応、/(ルート)で、実行してみました。 # du -sm /* ---------------------------------- 7 /bin 6 /boot 1 /dev 12 /etc 2491 /home 1 /initrd 44 /lib 1 /lost+found 1 /misc 1 /mnt 1 /opt ---------------------------------- /home以外はたいした容量ではないと思うのですが。。。 いろいろありがとうございました。 もう少し、地道に一杯になっているディレクトリを探してみます。
- tropic_snow
- ベストアンサー率61% (51/83)
> 3./配下のディレクトリ容量を見てみると > : > drwxr-xr-x 20 root root 118784 7月 5 12:11 dev ここの 118784 は、ディレクトリ配下のサイズではありません。あるディレクトリ配下のサイズを知りたい場合は次のコマンドを使用してください。 % du -sm /dir/path/* 例えば、/dir/path/の下にaaa,bbb,cccと3つのディレクトリがあるとすると、このコマンドの結果は 10 /dir/path/aaa 3 /dir/path/bbb 18 /dir/path/ccc のように、使用サイズ(単位はメガバイト)とディレクトリ/ファイル名が表示されます。 ルートディレクトリで実行する場合は、ルート権限で実行しないと意味がないでしょう。ただし、ルートディレクトリで実行するとHDD内の全ファイルを検索することになるので非常に時間がかかります。 おそらく、/home/の下がいっぱいなんじゃないですか? # du -sm /home/* とか、 # du -sm /home/user_name/* とかで確認してみてください。 ちなみに、/dev/配下は非常に重要なファイルです。 無駄なファイルもありますが、そもそもサイズが小さなものがたくさんあるだけなので、どれが必要なのか判断がつかない場合は、消さないほうが良いでしょう。
お礼
早速のご回答ありがとうございます。 >ここの 118784 は、ディレクトリ配下のサイズではありません。あるディレクトリ配下のサイズを知りたい場合は次のコマンドを使用してください。 そうなんですね。``r(^^;) ルートディレクトリで実行してみましたが、以下のように出ました。 --------------------------------------------------------------------- du: ディレクトリ `./proc/1052/fd' に移動できません: そのようなファイルやディレクトリはありません du: `./proc/1569/fd/4': そのようなファイルやディレクトリはありません 9534 . --------------------------------------------------------------------- >おそらく、/home/の下がいっぱいなんじゃないですか? ># du -sm /home/* >>とか、 ># du -sm /home/user_name/* >とかで確認してみてください。 /home/を確認してみました。 --------------------------------------------------------------------- 2491 /home --------------------------------------------------------------------- ちなみに他の使用率はこんな感じです。 Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda2 7052496 6682648 11600 100% / /dev/hda1 497829 13492 458635 3% /boot /dev/hda3 4032124 2582796 1244500 68% /home none 126696 0 126696 0% /dev/shm /dev/hda5 3020140 311512 2555212 11% /var >ちなみに、/dev/配下は非常に重要なファイルです。 >どれが必要なのか判断がつかない場合は、消さないほうが良いでしょう。 危うく消してしまうところでした。ありがとうございます。(^_^;) あとは、どこを確認すれば良いのでしょう???
お礼
いろいろと勉強させていただき、ありがとうございました。 今は、とりあえず動くようになりましたので、一安心ですが また、いつ使用量が100%になるかわかりませんので、こまめにチェックして いようと思います。 また、機会がありましたらご指導宜しくお願い致します。