October 22, 201213 yr I've rang the repair on all 3 drives and everything is now back up and running - a huge thanks to you both for your time. Now starts a big of a backup as some of the stuff wasn't overly important but some I doubt I could replace so its being stored on a 400GB IDE drive for safe keeping Great news indeed. Good idea to backup precious data to a external drive for safe-keeping. The drive drive you questioned about being a parity drive - I 100% knew this was a data disk so ran the same fix being pretty sure from the syslog output you extracted to show me the system rewriting the MBR on 3 drives, it must have done this drive too. Its now running as a data drive, mounted and I can browse it fine. Strange DD output still mind: The "dd" command I asked you to run stops printing after 30 lines of output. Your disk has other "junk values" at lower addresses, so it has not yet reached the "R e I s E r F s " string by the time 30 lines have printed. You can see that as the addresses stop at address 0004640. (The file system starts at address 0097840 if at sector 63) . You might help me to learn more by changing the 30q at the end if the command to this and try again: dd if=/dev/sdb count=195 | od -c -A d | sed '/R\ \ \ e\ \ \ I\ \ \ s\ \ \ E\ \ \ r\ \ \ 2\ \ \ F\ \ \ s/q' (There are three spaces between each letter in the string. The backslashes are for clairity. You could probably type: dd if=/dev/sdb count=195 | od -c -A d | sed '/R e I s E r 2 F s/q' As long as you type R space space space e space space space I space space space s ...... etc... Easiest might just be to cut and paste the command. Was the drive precleared before you first put it in service? One possibility is the extra stuff is just left over from the disk's prior use. (The first 62 sectors are unused in unRAID, since it starts its fie system on sector 63 or sector 64. If not zeroed, the extra stuff would still be there... it does no harm, just complicated my analysis since I was not looking for it to add extra lines of output to our commands) Now I have my data back, what is the correct proceedure to deal with the parity drive as I haven't assign it back in yet as it will no longer valid (when I initially started the array its started to do a sync)? Just stop the array, re-assign the parity drive, and re-start it. It should then calculate parity on the array. Joe L.
October 22, 201213 yr Joe L, not to hijack the thread, but as I was running commands to see what the output would be for me, I came across a few things that were odd to say the least. Testing a few of my disks I noticed this: sdc (disk 2) does not appear to have a reiserfs partition, but is detected fine and the unraid ui reports a reiserfs filesystem starting on sector 64. Running the dd command gives this: root@Media:/boot# dd if=/dev/sdc count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00668019 s, 14.9 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 360 z 250 256 \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * [b]0032256 353 R 220 N T F S \0 002 \b \0 \0[/b] 0032272 \0 \0 \0 \0 \0 370 \0 \0 ? \0 377 \0 ? \0 \0 \0 0032288 \0 \0 \0 \0 200 \0 200 \0 @ g 250 256 \0 \0 \0 \0 0032304 \0 \0 \f \0 \0 \0 \0 \0 t 206 352 \n \0 \0 \0 \0 0032320 366 \0 \0 \0 001 \0 \0 \0 245 026 240 240 V 240 240 ~ 0032336 \0 \0 \0 \0 372 3 300 216 320 274 \0 | 373 270 300 \a 0032352 216 330 350 026 \0 270 \0 \r 216 300 3 333 306 006 016 \0 0032368 020 350 S \0 h \0 \r h j 002 313 212 026 $ \0 264 0032384 \b 315 023 s 005 271 377 377 212 361 f 017 266 306 @ f 0032400 017 266 321 200 342 ? 367 342 206 315 300 355 006 A f 017 0032416 267 311 f 367 341 f 243 \0 303 264 A 273 252 U 212 0032432 026 $ \0 315 023 r 017 201 373 U 252 u \t 366 301 001 0032448 t 004 376 006 024 \0 303 f ` 036 006 f 241 020 \0 f 0032464 003 006 034 \0 f ; 006 \0 017 202 : \0 036 f j 0032480 \0 f P 006 S f h 020 \0 001 \0 200 > 024 \0 \0 0032496 017 205 \f \0 350 263 377 200 > 024 \0 \0 017 204 a \0 0032512 264 B 212 026 $ \0 026 037 213 364 315 023 f X [ \a 0032528 f X f X 037 353 - f 3 322 f 017 267 016 030 \0 0032544 f 367 361 376 302 212 312 f 213 320 f 301 352 020 367 6 0032560 032 \0 206 326 212 026 $ \0 212 350 300 344 006 \n 314 270 0032576 001 002 315 023 017 202 031 \0 214 300 005 \0 216 300 f 0032592 377 006 020 \0 377 016 016 \0 017 205 o 377 \a 037 f a The disk has been in my server since the start, was precleared 2 times before being put in the server and is 300GB from being full, so I know there's no issue with the disk. The extra "junk" in the first 63 sectors caused the command to end before the reisersrfs string. (it ended at address 0032592, the reiserfs string is usually at address 0097840 or 0098352 ) As I said in my prior post, it only printed the first 30 lines and then "q" (quit) I see "353 R 220 N T F S \0 002 \b \0 \0" at a low address, so I'm guessing you did something involving N T F S, or did not clear the drive, or a hardware device (or a virus) has put something in the first usually empty sectors. Virus writers love to hide stuff there, as the sectors are normally unused on almost all "windows" servers. My cache drive also reports a reiserfs filesystem, but reports this with dd: root@Media:/boot# dd if=/dev/sdf count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00228165 s, 43.8 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 360 _ 8 : \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001008 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 024 0001024 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0002048 N A P P _ S T A R T \0 \0 \0 \0 \0 \0 0002064 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0002560 M o n 0 1 / 1 1 / 2 0 1 0 0002576 0 : 0 2 : 2 3 . 5 9 L X W G H 0002592 0 2 0 3 6 0 0 1 B A 2 B 4 2 2 0 0002608 0 - - - 0002624 - P r e l o a d O K ! \r \n 0002640 $ \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0002656 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0003584 S E T S E R V E R = P R E L O 0003600 A D 7 A \r \n $ v \0 | \0 202 \0 210 \0 216 0003616 \0 224 \0 _ ^ 311 313 220 U 213 354 270 \n \0 232 276 0003632 002 x 6 V W 213 ^ 006 212 \a % 377 \0 P 232 \0 0003648 \0 5 6 203 304 002 210 F 370 213 ^ 006 212 G 001 % 0003664 377 \0 P 232 \0 \0 5 6 203 304 002 210 F 372 212 F 0003680 372 % 377 \0 211 F 366 212 F 370 % 377 \0 003 300 003 0003696 300 003 300 003 300 213 N 366 003 301 210 F 374 212 F 374 Was just wondering what your thoughts were on this. Again, the extra stuff in the first 63 sectors of the disk caused the initial printout to end prior to sector 63 at address 0003696. Your cache drive shows the string: SET SERVER=PRELOAD7A at a low address. Again, I doubt it was precleared. Does "SERVER=PRELOAD7A" mean anything to you? You too can try the same alternate commands I listed in my prior post, to quit when it gets to the R e I s E r F s 2 string. Joe L.
October 22, 201213 yr i bet the drive was previously in an OEM like Lenovo, dell, or HP and that is the signature for the recovery systems.
October 22, 201213 yr Author Thanks Joe L - I would guess the 1TB drive was never pre-cleared as I'm pretty sure it was before I knew the pre-clear script existed. I have an additonal 2TB HDD which has already been pre_cleared ready for us so as this is the only drive with anything strange going on, once I've got the parity checked/created I'm very tempted to swap out the 1TB drive in question with my new 2TB. I'm at work so I won't be able to do anything till uk evening time but I'll run those DD commands later and post back to results
October 22, 201213 yr Author Heres the DD output upto the data we're looking for root@unraid:~# dd if=/dev/sdc count=195 | od -c -A d | sed '/R e I s E r 2 F s/q' 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 ? \0 \0 \0 q m p t \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001536 ` 003 001 \0 240 005 002 \0 341 031 \0 \0 210 341 001 \0 0001552 P 002 001 \0 \0 \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 0001568 \0 200 \0 \0 \0 200 \0 \0 340 3 \0 \0 # \v 273 K 0001584 # \v 273 K 023 \0 036 \0 S 357 001 \0 001 \0 \0 \0 0001600 G 330 251 K \0 N 355 \0 \0 \0 \0 \0 001 \0 \0 \0 0001616 \0 \0 \0 \0 \v \0 \0 \0 200 \0 \0 \0 004 \0 \0 \0 0001632 006 \0 \0 \0 001 \0 \0 \0 s R 024 004 2 323 A 216 0001648 272 315 A 034 251 + * ? \0 \0 \0 \0 \0 \0 \0 \0 0001664 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001760 \b \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 y @ \t 0001776 377 313 H 330 201 D 314 326 267 230 005 O 002 001 \0 \0 0001792 \0 \0 \0 \0 \0 \0 \0 \0 G 330 251 K 250 001 \0 \0 0001808 251 001 \0 \0 252 001 \0 \0 253 001 \0 \0 254 001 \0 \0 0001824 255 001 \0 \0 256 001 \0 \0 257 001 \0 \0 260 001 \0 \0 0001840 261 001 \0 \0 262 001 \0 \0 263 001 \0 \0 264 001 \0 \0 0001856 265 005 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 0001872 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0004608 002 \0 \0 \0 003 \0 \0 \0 004 \0 \0 \0 O n 321 3 0004624 003 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0004640 002 200 \0 \0 003 200 \0 \0 004 200 \0 \0 H s 261 3 0004656 \n \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0004672 \0 \0 001 \0 001 \0 001 \0 002 \0 001 \0 230 } 023 3 0004688 016 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0004704 002 200 001 \0 003 200 001 \0 004 200 001 \0 Y ~ 331 3 0004720 004 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0004736 \0 \0 002 \0 001 \0 002 \0 002 \0 002 \0 377 003 340 3 0004752 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0008704 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 * 0009264 377 377 377 377 377 ? \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0009280 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0010496 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0010512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0011008 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0011024 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0011520 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0011536 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0012800 377 177 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0012816 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0014448 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 377 377 377 377 0014464 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 * 0016896 \0 \0 \0 \0 \0 \0 \0 \0 G 330 251 K G 330 251 K 0016912 G 330 251 K \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0016928 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0017024 355 A \0 \0 \0 020 \0 \0 G 330 251 K $ \v 273 K 0017040 $ \v 273 K \0 \0 \0 \0 \0 \0 \a \0 \b \0 \0 \0 0017056 \0 \0 \0 \0 \0 \0 \0 \0 243 001 \0 \0 \0 \0 \0 \0 0017072 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0017792 200 201 \0 \0 \0 \0 \0 001 \0 \0 \0 \0 H 330 251 K 0017808 H 330 251 K \0 \0 \0 \0 \0 \0 001 \0 0 200 \0 \0 0017824 \0 \0 \0 \0 \0 \0 \0 \0 250 001 \0 \0 251 001 \0 \0 0017840 252 001 \0 \0 253 001 \0 \0 254 001 \0 \0 255 001 \0 \0 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00646794 s, 15.4 MB/s 0017856 256 001 \0 \0 257 001 \0 \0 260 001 \0 \0 261 001 \0 \0 0017872 262 001 \0 \0 263 001 \0 \0 264 001 \0 \0 265 005 \0 \0 0017888 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0018176 300 A \0 \0 \0 @ \0 \0 G 330 251 K G 330 251 K 0018192 G 330 251 K \0 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 0018208 \0 \0 \0 \0 \0 \0 \0 \0 244 001 \0 \0 245 001 \0 \0 0018224 246 001 \0 \0 247 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0018240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0018304 240 201 \0 \0 \0 \0 \0 \0 h 333 251 K h 333 251 K 0018320 h 333 251 K \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \0 \0 0018336 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0018400 \0 \0 \0 \0 t 202 215 030 \0 \0 \0 \0 \0 \0 \0 \0 0018416 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0018432 355 A \0 \0 \0 020 \0 \0 337 333 251 K I 334 251 K 0018448 I 334 251 K \0 \0 \0 \0 \0 \0 002 \0 \b \0 \0 \0 0018464 \0 \0 \0 \0 \0 \0 \0 \0 \0 8 \0 \0 \0 \0 \0 \0 0018480 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0018528 \0 \0 \0 \0 366 031 321 306 \0 \0 \0 \0 \0 \0 \0 \0 0018544 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0018560 200 201 \0 \0 253 001 \0 \0 030 334 251 K 030 334 251 K 0018576 030 334 251 K \0 \0 \0 \0 \0 \0 001 \0 \b \0 \0 \0 0018592 \0 \0 \0 \0 \0 \0 \0 \0 \0 X \0 \0 \0 \0 \0 \0 0018608 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0018656 \0 \0 \0 \0 367 031 321 306 \0 \0 \0 \0 \0 \0 \0 \0 0018672 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0018688 200 201 \0 \0 311 001 \0 \0 I 334 251 K I 334 251 K 0018704 I 334 251 K \0 \0 \0 \0 \0 \0 001 \0 \b \0 \0 \0 0018720 \0 \0 \0 \0 \0 \0 \0 \0 \0 H \0 \0 \0 \0 \0 \0 0018736 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0018784 \0 \0 \0 \0 370 031 321 306 \0 \0 \0 \0 \0 \0 \0 \0 0018800 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0097792 256 \r 216 016 5 W \0 - 215 300 \r 022 \0 \0 \0 0097808 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 354 ; 351 & 0097824 204 003 \0 \0 036 \0 \0 \0 \0 \0 \0 \0 \0 020 314 003 0097840 0 \0 002 \0 R e I s E r 2 F s \0 \0 \0 I expect its exactly as you think, the drive just wasn't precleared before its original use. I'm pretty sure my first couple new drives we're formatted by unraid itself. I've reassigned the parity so its now chugging away at around 49,104 KB/sec so Its going to be after work tomorrow before I can start doing anything worth while again. Until I've been running it with the parity checked for a few days, I'm going to hold off on reinstalling the media downloaders/managers just to be safe.
October 22, 201213 yr Thanks for the explanation Joe, Im betting those drives were in the first batch of drives I precleared, one of which did in fact come from a OEM machine. Been too long now but something wonky did happen when I precleared those, I think at the time the server was still in its temporary home when I ran the preclear, I came home from work and the server was unresponsive so I had to hard reboot. I can't remember if I had parity at the time. Oh well, everything works so no point fretting with it, no parity errors. Thanks again
October 23, 201213 yr Author Its all looking good guys - parity sync has completed and I've ran a parity check straight away the evening after and its completed finding 0 errors so I think I'm back to working status again Cheers for the assistance - very much appreciated.
October 23, 201213 yr Its all looking good guys - parity sync has completed and I've ran a parity check straight away the evening after and its completed finding 0 errors so I think I'm back to working status again Cheers for the assistance - very much appreciated. Good. Now, report the bug in 4.7 to lime-tech. Point him to this thread. It turned out fine for you, but it could have been far worse. You will not be the last person that is running on 4.7 who has to replace a flash drive. Joe L.
October 23, 201213 yr Is there a specific place to report bugs? AFAIK, no... the thread for the 4.7 release is not a good spot today, as I doubt anyone is looking at it. There are three known issues in 4.7. The issue you hit is one of them. Best is to notify Tom @ lime-tech via PM to "limetech" and e-mail: [email protected] and [email protected].
Archived
This topic is now archived and is closed to further replies.