1 |
All, |
2 |
|
3 |
I'm in desperate need of some help recovering a reiserfs partition |
4 |
that went awry for some unknown reason. A quick list of events: |
5 |
|
6 |
- purchased brand new WD "My Passport" drive -- 320GB, 2.5GB |
7 |
- cleared partition table with a "dd if=/dev/urandom of=/dev/sdX bs=5M count=10" |
8 |
- created one single large partition |
9 |
- mkreiserfs /dev/sdX |
10 |
- copied data into the new hard drive |
11 |
|
12 |
All seemed well. I mounted the partition, copied critical data into |
13 |
the partition, then *cleanly* unmounted the partition after confirming |
14 |
that all the data was on the drive with no issues. Then "it the the |
15 |
fan": |
16 |
|
17 |
Upon attempting to remount the partition, the partition would not |
18 |
mount. In fact, upon attempting to remount the partition, here's what |
19 |
happens (according to /var/log/dmesg): |
20 |
|
21 |
-->8-- |
22 |
|
23 |
[18723.893570] usb-storage: device found at 8 |
24 |
[18723.893572] usb-storage: waiting for device to settle before scanning |
25 |
[18728.893199] usb-storage: device scan complete |
26 |
[18728.895310] scsi 13:0:0:0: Direct-Access WD My Passport |
27 |
071A 2011 PQ: 0 ANSI: 4 |
28 |
[18728.897305] scsi 13:0:0:1: Enclosure WD SES Device |
29 |
2011 PQ: 0 ANSI: 4 |
30 |
[18728.898987] sd 13:0:0:0: Attached scsi generic sg4 type 0 |
31 |
[18728.899119] ses 13:0:0:1: Attached Enclosure device |
32 |
[18728.899222] ses 13:0:0:1: Attached scsi generic sg5 type 13 |
33 |
[18728.901909] sd 13:0:0:0: [sdf] 625086464 512-byte logical blocks: |
34 |
(320 GB/298 GiB) |
35 |
[18728.905166] sd 13:0:0:0: [sdf] Write Protect is off |
36 |
[18728.905170] sd 13:0:0:0: [sdf] Mode Sense: 2b 00 10 08 |
37 |
[18728.905173] sd 13:0:0:0: [sdf] Assuming drive cache: write through |
38 |
[18728.910673] sd 13:0:0:0: [sdf] Assuming drive cache: write through |
39 |
[18728.910677] sdf: sdf1 |
40 |
[18728.954536] sd 13:0:0:0: [sdf] Assuming drive cache: write through |
41 |
[18728.954541] sd 13:0:0:0: [sdf] Attached SCSI disk |
42 |
[18729.204285] REISERFS (device sdf1): found reiserfs format "3.6" |
43 |
with standard journal |
44 |
[18729.204305] REISERFS (device sdf1): using ordered data mode |
45 |
[18729.233424] REISERFS (device sdf1): journal params: device sdf1, |
46 |
size 8192, journal first block 18, max trans len 1024, max batch 900, |
47 |
max commit age 30, max trans age 30 |
48 |
[18729.233645] REISERFS (device sdf1): checking transaction log (sdf1) |
49 |
[18730.204418] REISERFS warning: reiserfs-5090 is_tree_node: node |
50 |
level 5687 does not match to the expected one 65534 |
51 |
[18730.204422] REISERFS error (device sdf1): vs-5150 search_by_key: |
52 |
invalid format found in block 0. Fsck? |
53 |
[18730.204426] REISERFS (device sdf1): Remounting filesystem read-only |
54 |
[18730.204430] REISERFS error (device sdf1): vs-13070 |
55 |
reiserfs_read_locked_inode: i/o failure occurred trying to find stat |
56 |
data of [1 2 0x0 SD] |
57 |
[18730.204436] REISERFS (device sdf1): Using r5 hash to sort names |
58 |
root@gentoo:~# fdisk -l /dev/sdf |
59 |
|
60 |
Disk /dev/sdf: 320.0 GB, 320044269568 bytes |
61 |
255 heads, 63 sectors/track, 38909 cylinders |
62 |
Units = cylinders of 16065 * 512 = 8225280 bytes |
63 |
Sector size (logical/physical): 512 bytes / 512 bytes |
64 |
I/O size (minimum/optimal): 512 bytes / 512 bytes |
65 |
Disk identifier: 0x2dbafd11 |
66 |
|
67 |
Device Boot Start End Blocks Id System |
68 |
/dev/sdf1 1 38909 312536511 83 Linux |
69 |
|
70 |
--8<-- |
71 |
|
72 |
I know the data is in tact because (a) I have not written anything to |
73 |
the disk, and (b) using tools like foremost / scalpel have |
74 |
successfully "restored" much of the data on the drive. (unfortunately |
75 |
foremost does not restore file names and it'll be incredibly difficult |
76 |
for me to properly restore the previous data structure) |
77 |
|
78 |
I've attempted to recover the drive using "reiserfsck |
79 |
--scan-whole-partition --rebuild-tree /dev/sdf1", to no avail: |
80 |
|
81 |
-->8-- |
82 |
|
83 |
root@gentoo:~# reiserfsck --scan-whole-partition --rebuild-tree /dev/sdf1 |
84 |
reiserfsck 3.6.21 (2009 www.namesys.com) |
85 |
|
86 |
*snip* |
87 |
|
88 |
Will rebuild the filesystem (/dev/sdf1) tree |
89 |
Will put log info to 'stdout' |
90 |
|
91 |
Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes |
92 |
Replaying journal: No transactions found |
93 |
########### |
94 |
reiserfsck --rebuild-tree started at Tue Aug 24 01:46:49 2010 |
95 |
########### |
96 |
|
97 |
Pass 0: |
98 |
####### Pass 0 ####### |
99 |
The whole partition (78134112 blocks) is to be scanned |
100 |
Skipping 10595 blocks (super block, journal, bitmaps) 78123517 blocks |
101 |
will be read |
102 |
0%....20%....40%... left |
103 |
0, 8521 /seccsecccccseccccc |
104 |
Could not find a hash in use. Using "r5" |
105 |
"r5" hash is selected |
106 |
Flushing..finished |
107 |
Read blocks (but not data blocks) 78123517 |
108 |
Leaves among those 0 |
109 |
Objectids found 2 |
110 |
|
111 |
Pass 1 (will try to insert 0 leaves): |
112 |
####### Pass 1 ####### |
113 |
Looking for allocable blocks .. finished |
114 |
|
115 |
Flushing..finished |
116 |
0 leaves read |
117 |
0 inserted |
118 |
####### Pass 2 ####### |
119 |
Flushing..finished |
120 |
|
121 |
|
122 |
No reiserfs metadata found. If you are sure that you had the reiserfs |
123 |
on this partition, then the start of the partition might be changed |
124 |
or all data were wiped out. The start of the partition may get changed |
125 |
by a partitioner if you have used one. Then you probably rebuilt the |
126 |
superblock as there was no one. Zero the block at 64K offset from the |
127 |
start of the partition (a new super block you have just built) and try |
128 |
to move the start of the partition a few cylinders aside and check if |
129 |
debugreiserfs /dev/xxx detects a reiserfs super block. If it does this |
130 |
is likely to be the right super block version. |
131 |
If this makes you nervous, try www.namesys.com/support.html, and for |
132 |
$25 the author of fsck, or a colleague if he is out, will step you |
133 |
through it all. |
134 |
|
135 |
Aborted (core dumped) |
136 |
|
137 |
--8<-- |
138 |
|
139 |
The issue seems to be the *superblock* is not correct. I confirmed |
140 |
with a "reiserfsck --check /dev/sdf1" |
141 |
|
142 |
-->8-- |
143 |
|
144 |
root@gentoo:~# reiserfsck --check /dev/sdf1 |
145 |
reiserfsck 3.6.21 (2009 www.namesys.com) |
146 |
|
147 |
*snip* |
148 |
|
149 |
Will read-only check consistency of the filesystem on /dev/sdf1 |
150 |
Will put log info to 'stdout' |
151 |
|
152 |
Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes |
153 |
########### |
154 |
reiserfsck --check started at Tue Aug 24 04:48:00 2010 |
155 |
########### |
156 |
Replaying journal: No transactions found |
157 |
Checking internal tree.. |
158 |
|
159 |
Bad root block 0. (--rebuild-tree did not complete) |
160 |
|
161 |
Aborted (core dumped) |
162 |
|
163 |
--8<-- |
164 |
|
165 |
I've also attempted to rebuild the superblock (which seems to be the |
166 |
big problem here), but this didn't work either. |
167 |
|
168 |
-->8-- |
169 |
|
170 |
root@gentoo:~# reiserfsck --rebuild-sb /dev/sdf1 |
171 |
reiserfsck 3.6.21 (2009 www.namesys.com) |
172 |
|
173 |
*snip* |
174 |
|
175 |
Will check superblock and rebuild it if needed |
176 |
Will put log info to 'stdout' |
177 |
|
178 |
Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes |
179 |
rebuild-sb: wrong tree height occured (65535), zeroed |
180 |
Reiserfs super block in block 16 on 0x851 of format 3.6 with standard journal |
181 |
Count of blocks on the device: 78134112 |
182 |
Number of bitmaps: 2385 |
183 |
Blocksize: 4096 |
184 |
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] |
185 |
blocks): 78134112 |
186 |
Root block: 0 |
187 |
Filesystem is NOT clean |
188 |
Tree height: 0 |
189 |
Hash function used to sort names: "r5" |
190 |
Objectid map size 2, max 972 |
191 |
Journal parameters: |
192 |
Device [0x0] |
193 |
Magic [0x0] |
194 |
Size 8193 blocks (including 1 for journal header) (first block 18) |
195 |
Max transaction length 1024 blocks |
196 |
Max batch size 900 blocks |
197 |
Max commit age 30 |
198 |
Blocks reserved by journal: 0 |
199 |
Fs state field: 0xfa03: |
200 |
FATAL corruptions exist. |
201 |
some corruptions exist. |
202 |
sb_version: 2 |
203 |
inode generation number: 0 |
204 |
UUID: 1704f9d1-2de0-40f7-8f73-aa3cbd6b35ba |
205 |
LABEL: |
206 |
Set flags in SB: |
207 |
Mount count: 0 |
208 |
Maximum mount count: Disabled. Run fsck.reiserfs(8) or use |
209 |
tunefs.reiserfs(8) to enable. |
210 |
Last fsck run: Never with a version that supports this feature. |
211 |
Check interval in days: Disabled. Run fsck.reiserfs(8) or use |
212 |
tunefs.reiserfs(8) to enable. |
213 |
Is this ok ? (y/n)[n]: y |
214 |
The fs may still be unconsistent. Run reiserfsck --check. |
215 |
|
216 |
--8<-- |
217 |
|
218 |
I apologize of the long post; I'm in a pretty big pickle and am |
219 |
desperate for some help. The data is on the drive -- what bothers me |
220 |
is that this randomly happened. The portable drive was cleanly |
221 |
unmounted so I can't really see what could have caused this issue. |
222 |
|
223 |
Any thoughts, ideas, or beer to get over this issue would be greatly |
224 |
appreciated. |
225 |
|
226 |
Thanks! |
227 |
-james |