-PR-
解決済み

ディスク容量がいっぱいになってしまいました。。。

  • すぐに回答を!
  • 質問No.1493048
  • 閲覧数1983
  • ありがとう数8
  • 気になる数0
  • 回答数6
  • コメント数0

お礼率 86% (32/37)

皆様よりご教授賜りたく宜しくお願い致します。

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
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

質問者が選んだベストアンサー

  • 回答No.6
レベル9

ベストアンサー率 60% (12/20)

こんにちは。またまた御邪魔します。

使用量が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にとって重要なものばかりなので、消さないようにしましょう。
お礼コメント
MMM-SRV

お礼率 86% (32/37)

いろいろと勉強させていただき、ありがとうございました。
今は、とりあえず動くようになりましたので、一安心ですが
また、いつ使用量が100%になるかわかりませんので、こまめにチェックして
いようと思います。

また、機会がありましたらご指導宜しくお願い致します。
投稿日時 - 2005-07-08 13:54:05

その他の回答 (全5件)

  • 回答No.5
レベル9

ベストアンサー率 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 コマンドに相当するのは、フォルダを右クリックして「プロパティ」ですね。
お礼コメント
MMM-SRV

お礼率 86% (32/37)

細かくご説明頂きありがとうございました!!
なるほど・・・。個々のファイルサイズが小さくてもファイルが増えれば増える程入れ物(ブロック)が必要になるということですね。
一度、広げた入れ物は小さくならない。小さくならないけれども、ファイルが減れば、中は空になっているっということで、使用量は、当然減るのですよね?

>/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
投稿日時 - 2005-07-08 11:43:29


  • 回答No.1
レベル9

ベストアンサー率 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/配下は非常に重要なファイルです。
無駄なファイルもありますが、そもそもサイズが小さなものがたくさんあるだけなので、どれが必要なのか判断がつかない場合は、消さないほうが良いでしょう。
お礼コメント
MMM-SRV

お礼率 86% (32/37)

早速のご回答ありがとうございます。

>ここの 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/配下は非常に重要なファイルです。
>どれが必要なのか判断がつかない場合は、消さないほうが良いでしょう。

危うく消してしまうところでした。ありがとうございます。(^_^;)
あとは、どこを確認すれば良いのでしょう???
投稿日時 - 2005-07-05 14:14:56
  • 回答No.2
レベル9

ベストアンサー率 61% (51/83)

/(ルート)と/homeは別パーティションだったんですね。
だとすると、先程の

> おそらく、/home/の下がいっぱいなんじゃないですか?

は、間違いです。すみません。

さて、だとすると、どこが一杯になってるんでしょうね?/boot,/home,/varは別なので、それ以外を地道に見ていくしかないかも。あ、/procと/tmpも外してくださいね。

# du -sm /misc
# du -sm /opt
# du -sm /root
:

という感じで…。
お礼コメント
MMM-SRV

お礼率 86% (32/37)

>/(ルート)と/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以外はたいした容量ではないと思うのですが。。。
いろいろありがとうございました。
もう少し、地道に一杯になっているディレクトリを探してみます。
投稿日時 - 2005-07-05 15:43:55
  • 回答No.3
レベル9

ベストアンサー率 70% (51/72)

/ 配下ですよね、もしかして「/」ディレクトリ内に大きな core ファイルや一時ファイルが作成されていませんでしょうか。「/tmp」にも大きなファイルがあるかもしれません。
お礼コメント
MMM-SRV

お礼率 86% (32/37)

「/」ディレクトリには、フォルダしかないようです。
「/tmp」にも、特別大きなファイルはありませんでした。。。

ちなみに、du -sm ではサブディレクトリ内の容量も合計して算出されているのでしょうか???
投稿日時 - 2005-07-06 10:26:07
  • 回答No.4
レベル9

ベストアンサー率 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 /

の結果はどうでしょうか。
お礼コメント
MMM-SRV

お礼率 86% (32/37)

返事が遅くなり済みません。ご回答ありがとうございます。

># 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のディレクトリの概念と少し異なるようで、戸惑っています。。。
ここで指摘されている >消費しているブロック数 とは、使用量とは違うのでしょうか?
投稿日時 - 2005-07-07 10:05:58
このQ&Aで解決しましたか?
AIエージェント「あい」

こんにちは。AIエージェントの「あい」です。
あなたの悩みに、OKWAVE 3,500万件のQ&Aを分析して最適な回答をご提案します。

関連するQ&A
このQ&Aにこう思った!同じようなことあった!感想や体験を書こう
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-

特集


抽選で合計100名様にプレゼント!

ピックアップ

ページ先頭へ