muneda's diary(2006-08-07)

2006-08-07 曇りのち晴れ．雲が多く夏っぽい空 [長年日記]

_1 Ext3 ファイルシステムで削除したファイルを復元について (2)

前にやったExt3 ファイルシステムで削除したファイルを復元についての再チャレンジ．

まずはext3パーティションをマウント．*1

# cat /proc/mounts G ext3
# mount /boot
# cat /proc/mounts G ext3
/dev/hda1 /boot ext3 rw,noatime,data=ordered 0 0

ext3ファイルシステム上にファイルを作成し削除する．

# cd /boot
# nano muneda.txt
# cat muneda.txt
This file is on the ext3 filesystem.
# rm muneda.txt
rm: remove 通常ファイル `muneda.txt'? y

ファイルシステムを破壊しないよう念のためext3パーティションをアンマウント

# cd -
/home/muneda/ext3/060802
# umount /boot
# cat /proc/mounts G ext3

以下，みたさんところの手順にしたがって作業．

# dumpe2fs /dev/hda1 G 'Block size'
dumpe2fs 1.38 (30-Jun-2005)
Block size:               1024

grepではなくperlスクリプトで削除データを探す．検索キーワードは ext3 filesystem とした．

# cat ext3-file-rescue.pl
#!/usr/bin/perl

$block_size = 1024;
$blkno = 0;
open(FH, "< /dev/hda1") or die "can't open $!";
while (read(FH, $block, $block_size)) {
       if ($block =~ m|ext3 filesystem|) {
               print "$blkno\n";
       }
       $blkno += 1;
}
# perl ext3-file-rescue.pl > list
# cat list
25610
25611
28161
30089
30209
# cat list | while read i; do
dd if=/dev/hda1 of=$i.data bs=1024 count=1 skip=$(($i/1024))
done
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.022163 seconds, 46.2 kB/s
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.000392 seconds, 2.6 MB/s
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.00056 seconds, 1.8 MB/s
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.000328 seconds, 3.1 MB/s
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.000546 seconds, 1.9 MB/s

復旧できたデータを確認．

# ll -1v *data
-rw-r--r-- 1 root root 1024 2006-08-02 15:39 25610.data
-rw-r--r-- 1 root root 1024 2006-08-02 15:39 25611.data
-rw-r--r-- 1 root root 1024 2006-08-02 15:39 28161.data
-rw-r--r-- 1 root root 1024 2006-08-02 15:39 30089.data
-rw-r--r-- 1 root root 1024 2006-08-02 15:39 30209.data

Emacs の hexl-mode で中身をのぞいてみたが，いずれもファイルの内容がNULLで埋めつくされたファイルだった．

ファイルの内容が小さすぎるのがダメかなと思い，dmesgの内容を出力したファイルを削除してキーワードを 'gentoo' としてみたが変わらず，ファイルの中身がNULLで埋めつくされたファイルだった．ちなみにdmesgの中身はこんな感じ．先頭行にgentooの文字が見える．

# dmesg | head
Linux version 2.6.17-gentoo-r2 (root@mux06) \
(gcc バージョン 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)) \
#1 SMP PREEMPT Tue Jul 11 17:31:15 JST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001f6f0000 (usable)
BIOS-e820: 000000001f6f0000 - 000000001f6f3000 (ACPI NVS)
BIOS-e820: 000000001f6f3000 - 000000001f700000 (ACPI data)
BIOS-e820: 000000001f700000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)

ということで今回も失敗．うーむ，よく分からん．

追記(20061127): Ext3で削除したファイル復元については20060808の記事を参考にしてください．

Tags: Linux

*1 Gはzshのglobal aliasで "|grep" に設定されている

_2 SCSIディスクの台数制限

ディスク台数に依存する性能測定をしようと思い，FibreChannel経由で大量のディスク(といっても512台)を接続．ドライバのオプションでKernelから見えるディスク数を制限することにした．

/etc/modprobe.confに

options scsi_mod max_luns=256

と書けばSCSIカードだろうがFCカードだろうがどちらに繋がれたディスクでも先頭から256台までしか認識されないと思っていたのだが，/proc/partitionsを見るとどうやら制限されずにすべて見えてしまっている．念のためinitrdの中身を展開して，modprobe.confの内容が反映されていることを確認している．なので編集内容もinitrdの作り方も問題ない．

同じく

options lpfc lpfc_max_luns=128

だけ書いてもすべて見えてしまっている．

ようわからんようになってきたので，ダメもとで

options scsi_mod max_luns=128
options lpfc lpfc_max_luns=128

と書いたところ，前者はうまく効いていないが後者がうまく効いたようで，SCSI経由の2台＋2枚のFCカードそれぞれ経由の129x2台のトータル260台だけが認識されるようになった(パラメータの理解が間違っていた．lpfc_max_lunsの値0から始まるので，この場合先頭から129台目まで認識される)．

数字の切りが悪いのでやり直そうかと思ったが，ダルかったのでこのまま続けた．それにしてもscsi_modのオプションが効かないのが気になる．

Tags: Linux Kernel