diary

ディレクトリ内のファイル数

without comments

先日、サーバのディスク容量が一杯だという話を受けて調査してみたところ、どうやら、とあるディレクトリが怪しいという見当までつけることができました。しかし、このディレクトリにはとにかく途方も無い数のファイルがあるらしく、lsすらいくら待ってもかえってきません。そうなると、この中にいったいどんだけのファイルが詰まっているのかというのが気になるのが人情というもの。

なんとなく思いついたのは、ディレクトリそのもののを大きさを見れば、ある程度見当がつくんじゃないかな、ということ。そこで、とりあえずディレクトリのサイズを調べてみました。

$ ls -l
drwxr-x--- 2 guest guest 401416192 Dec  11 14:39 dump

なんと400M。initialのblocksizeは4k(=4096)なので、なんと初期値の10万倍近い大きさです。

確か、ディレクトリはその下にあるファイルの名前とinode情報の詰め合わせじゃなかったっけ、と思って調べてみたら、readdirのman pageにそれらしきものを発見。

struct dirent {
    ino_t          d_ino;       /* inode number */
    off_t          d_off;       /* offset to the next dirent */
    unsigned short d_reclen;    /* length of this record */
    unsigned char  d_type;      /* type of file; not supported
                                   by all file system types */
    char           d_name[256]; /* filename */
}

ディレクトリそのものの中にはこの情報がびっしり詰まっている、という雰囲気なのかな。そうなると、実際に中を見て確認してみたくなるもの。ということでさらにいろいろと探してたら、Linuxのdumpfsというコマンドでそれができそうだということを発見。さっそく、適当にディレクトリと、そのなかにいくつかファイルを作ってためしに実行してみました。

$ ls -l
drwxr-xr-x  2 guest guest  4096 Dec 11 16:49 a

$ sudo /sbin/debugfs /dev/hda1
Password:
debugfs 1.39 (29-May-2006)
debugfs:  cd /home/guest
debugfs:  ls
 7962776  (12) .    7962775  (12) ..    7964517  (4072) a
debugfs:  dump a /home/guest/a_dump
debugfs:  close
debugfs:  quit

$ ls -l
drwxr-xr-x  2 guest   guest    4096 Dec 11 16:49 a
-rw-r--r--  1 root    root     4096 Dec 11 16:49 a_dump

ディレクトリと同じ大きさのファイルができました。すばらしい。中身を16進ダンプしてみます。

$ xxd a_dump

0000000: 6587 7900 0c00 0102 2e00 0000 9880 7900  e.y...........y.
0000010: 0c00 0202 2e2e 0000 6687 7900 1800 0a01  ........f.y.....
0000020: 5245 4144 4d45 2e74 7874 7377 7000 0000  README.txtswp...
0000030: 6787 7900 1000 0801 7465 7374 2e74 7874  g.y.....test.txt
0000040: ac87 7900 1400 0a01 696e 6465 782e 6874  ..y.....index.ht
0000050: 6d6c 0000 ad87 7900 1400 0c01 6465 6661  ml....y.....defa
0000060: 756c 742e 6874 6d6c 6f87 7900 1000 0601  ult.htmlo.y.....
0000070: 5245 4144 4d45 0000 7087 7900 1000 0701  README..p.y.....
0000080: 746d 702e 7478 7400 cab5 7900 1000 0801  tmp.txt...y.....
0000090: 6e61 762e 6874 6d6c cbb5 7900 1000 0801  nav.html..y.....
00000a0: 746f 632e 6874 6d6c ccb5 7900 580f 0801  toc.html..y.X...
00000b0: 746f 702e 6874 6d6c 0000 0000 0000 0000  top.html........
00000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

なるほどねーこうなってるのねー。

ここまでくれば、あとは同じことをこのバカでかいディレクトリに対してやればいいだけなのですが、なんかもうめんどくさいなぁということであっさり断念(実は途中でイラッときてファイルの削除をもう開始してた)。幸い、中に詰まっているファイル名の長さは大体23ってのがわかってたので、このダンプを眺めて、ファイル名とファイル名の間は平均して9バイト、とざっくりあたりをつけて、1ファイルあたりに必要な情報量は大体32バイトだろう、ということでざっと計算。

401416192 / 32 = 12544256

ということで、まあきっとこの中には1200万ほどのファイルがあるんじゃないか、という見当になりました。思ったよりは少ないな。あー、すっきりした。

ビール飲みながら調べてたので結構適当です。そうじゃねーよというご意見がありましたらぜひいただきたく。ちなみに、昨日全消去のコマンドを流しはじめたのですが、今日現在いまだ削除中です。OSから入れなおしたほうが早かったかも。

Written by Kei

December 12th, 2012 at 11:36 pm

Posted in Tech

Tagged with , , , , ,

Leave a Reply