Hi Guys,

 

I ran a parity check

I swapped my Parirty disk from a 1TB disk to a 2TB .

I did a parity sync to catch my new parity drive up.

I then added a 2nd 2TB disk to my array,

 

During the format and bringin online of the 2TB data disk my array got stuck in "Starting...."

 

Like a good boy I used search and found:

http://lime-technology.com/forum/index.php?topic=5933.0

 

I started to read through and took smartctl reports for each disk.

 

JoeL "You are looking for Re-Allocated sectors in the report, or sectors pending re-allocation."

 

Well each of my disks has Re-Allocated in the report I produced, and I'm now a little concerned!

 

On a side note, I've not seen any error count in the gui, I would run a parity check, but if I've imenant failure of a disk I'd rather try and get some data off them first...

 

 

Would somone mind having a read of my disk reports and suggesting "in their opion" if I'm likly to lose disks soon?

 

MANY THANKS!

A

sdb_0140_disk2.txt

sdd_5663_disk1.txt

sde_2333_disk3.txt

sdf_3541_disk_P.txt

Last disk report attached.

 

syslog attached from server after failed array startup (before I rebooted the server) it's now been rebooted and is back up and the array has started, but im still worried about my disks!!!!

 

syslog-22-09-2010_at_22.48_from_var.txt

sdg_1053_disk_4.txt

Last disk report attached.

syslog attached from server after failed array startup (before I rebooted the server) it's now been rebooted and is back up and the array has started, but im still worried about my disks!!!!

 

You are one of selected few now in this "Oops club", refer to following link for information.

 

http://lime-technology.com/forum/index.php?topic=6302.0

 

 

---------------------- from your syslog ------------------------------------------------------------

ep 22 06:59:30 unRAID-Server emhttp: ... clearing 88% complete

Sep 22 07:06:04 unRAID-Server emhttp: ... clearing 89% complete

Sep 22 07:12:47 unRAID-Server emhttp: ... clearing 90% complete

Sep 22 07:19:32 unRAID-Server emhttp: ... clearing 91% complete

Sep 22 07:26:20 unRAID-Server emhttp: ... clearing 92% complete

Sep 22 07:33:13 unRAID-Server emhttp: ... clearing 93% complete

Sep 22 07:40:10 unRAID-Server emhttp: ... clearing 94% complete

Sep 22 07:47:10 unRAID-Server emhttp: ... clearing 95% complete

Sep 22 07:54:18 unRAID-Server emhttp: ... clearing 96% complete

Sep 22 08:01:26 unRAID-Server emhttp: ... clearing 97% complete

Sep 22 08:08:39 unRAID-Server emhttp: ... clearing 98% complete

Sep 22 08:16:01 unRAID-Server emhttp: ... clearing 99% complete

Sep 22 08:23:33 unRAID-Server emhttp: ... clearing 100% complete

Sep 22 08:23:33 unRAID-Server emhttp: ... syncing

Sep 22 08:23:36 unRAID-Server kernel: mdcmd (20): start PROTECTED_EXPANSION

Sep 22 08:23:36 unRAID-Server kernel: unraid: allocating 28460K for 1280 stripes (5 disks)

Sep 22 08:23:36 unRAID-Server kernel: md1: running, size: 976762552 blocks

Sep 22 08:23:36 unRAID-Server kernel: md2: running, size: 976762552 blocks

Sep 22 08:23:36 unRAID-Server kernel: md3: running, size: 976762552 blocks

Sep 22 08:23:36 unRAID-Server kernel: md4: running, size: 1953514552 blocks

Sep 22 08:23:36 unRAID-Server kernel: mdcmd (22): spindown 0

Sep 22 08:23:37 unRAID-Server kernel: mdcmd (24): spindown 1

Sep 22 08:23:37 unRAID-Server kernel: BUG: unable to handle kernel paging request at f8bbf000

Sep 22 08:23:37 unRAID-Server kernel: IP: [<f8bb48c4>] md_cmd_proc_read+0x41/0x54 [md_mod]

Sep 22 08:23:37 unRAID-Server kernel: *pdpt = 0000000001428001 *pde = 000000000295a067 *pte = 0000000000000000

Sep 22 08:23:37 unRAID-Server kernel: Oops: 0000 [#1] SMP

Sep 22 08:23:37 unRAID-Server kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:08.0/host4/target4:0:0/4:0:0:0/block/sdd/stat

Sep 22 08:23:37 unRAID-Server kernel: Modules linked in: md_mod xor forcedeth sata_sil sata_nv amd74xx [last unloaded: md_mod]

Sep 22 08:23:37 unRAID-Server kernel:

Sep 22 08:23:37 unRAID-Server kernel: Pid: 19779, comm: emhttp Not tainted (2.6.31.12-unRAID #1) System Product Name

Sep 22 08:23:37 unRAID-Server kernel: EIP: 0060:[<f8bb48c4>] EFLAGS: 00210212 CPU: 1

Sep 22 08:23:37 unRAID-Server kernel: EIP is at md_cmd_proc_read+0x41/0x54 [md_mod]

Sep 22 08:23:37 unRAID-Server kernel: EAX: c2b9ff38 EBX: fffffc1c ECX: 3ffff1b2 EDX: fffffc1c

Sep 22 08:23:37 unRAID-Server kernel: ESI: f8bbf000 EDI: e8133554 EBP: c2b9ff04 ESP: c2b9fef4

Sep 22 08:23:37 unRAID-Server kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068

Sep 22 08:23:37 unRAID-Server kernel: Process emhttp (pid: 19779, ti=c2b9e000 task=d768e1c0 task.ti=c2b9e000)

Sep 22 08:23:37 unRAID-Server kernel: Stack:

Sep 22 08:23:37 unRAID-Server kernel:  c2b9ff38 f8bb4883 00000000 e8130000 c2b9ff4c c10982ad 00000400 c2b9ff3c

Sep 22 08:23:37 unRAID-Server kernel: <0> 00000000 00000400 00000000 00000400 b7769000 c40cd960 00000000 c40cd960

Sep 22 08:23:37 unRAID-Server kernel: <0> 00000400 e8130000 00000001 c40cd960 c10981a2 fffffffb c2b9ff70 c1094c9e

Sep 22 08:23:37 unRAID-Server kernel: Call Trace:

Sep 22 08:23:37 unRAID-Server kernel:  [<f8bb4883>] ? md_cmd_proc_read+0x0/0x54 [md_mod]

Sep 22 08:23:37 unRAID-Server kernel:  [<c10982ad>] ? proc_file_read+0x10b/0x22d

Sep 22 08:23:37 unRAID-Server kernel:  [<c10981a2>] ? proc_file_read+0x0/0x22d

Sep 22 08:23:37 unRAID-Server kernel:  [<c1094c9e>] ? proc_reg_read+0x56/0x6a

Sep 22 08:23:37 unRAID-Server kernel:  [<c1094c48>] ? proc_reg_read+0x0/0x6a

Sep 22 08:23:37 unRAID-Server kernel:  [<c1068146>] ? vfs_read+0x8a/0x114

Sep 22 08:23:37 unRAID-Server kernel:  [<c10684dd>] ? sys_read+0x3b/0x60

Sep 22 08:23:37 unRAID-Server kernel:  [<c1002975>] ? syscall_call+0x7/0xb

Sep 22 08:23:37 unRAID-Server kernel: Code: 55 f0 e8 3a 86 57 c8 8d 50 01 29 f2 39 d3 7c 0b 8b 45 0c 89 d3 c7 00 01 00 00 00 8b 45 f0 89 d9 81 c6 ac b6 bb f8 c1 e9 02 89 38 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 5a 89 d8 5b 5e 5f 5d c3 55 89

Sep 22 08:23:37 unRAID-Server kernel: EIP: [<f8bb48c4>] md_cmd_proc_read+0x41/0x54 [md_mod] SS:ESP 0068:c2b9fef4

Sep 22 08:23:37 unRAID-Server kernel: CR2: 00000000f8bbf000

Sep 22 08:23:37 unRAID-Server kernel: ---[ end trace 9610aa640feeb81b ]---

Sep 22 08:23:38 unRAID-Server kernel: mdcmd (25): spindown 2

Sep 22 08:23:39 unRAID-Server kernel: mdcmd (26): spindown 3

Sep 22 08:23:40 unRAID-Server kernel: mdcmd (27): spindown 4

 

JoeL "You are looking for Re-Allocated sectors in the report, or sectors pending re-allocation."

 

Well each of my disks has Re-Allocated in the report I produced, and I'm now a little concerned!

You are looking for a "raw" count greater than zero.  Your disks are fine.

By the way, I belong to the same club  (this was on 5.0-beta2 on my newer server):

Sep 22 15:33:41 Tower2 kernel: BUG: unable to handle kernel paging request at f82cd000

Sep 22 15:33:41 Tower2 kernel: IP: [] md_cmd_proc_read+0x41/0x54 [md_mod]

Sep 22 15:33:41 Tower2 kernel: *pdpt = 0000000001447001 *pde = 000000003740f067 *pte = 0000000000000000

Sep 22 15:33:41 Tower2 kernel: Oops: 0000 [#1] SMP

Sep 22 15:33:41 Tower2 kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:03:00.0/host2/target2:0:0/2:0:0:0/block/sda/stat

Sep 22 15:33:41 Tower2 kernel: Modules linked in: md_mod xor i2c_i801 i2c_core ahci sata_sil r8169

Sep 22 15:33:41 Tower2 kernel:

Sep 22 15:33:41 Tower2 kernel: Pid: 4784, comm: emhttp Not tainted (2.6.32.9-unRAID #5) C2SEA

Sep 22 15:33:41 Tower2 kernel: EIP: 0060:[] EFLAGS: 00210203 CPU: 1

Sep 22 15:33:41 Tower2 kernel: EIP is at md_cmd_proc_read+0x41/0x54 [md_mod]

Sep 22 15:33:41 Tower2 kernel: EAX: c232df38 EBX: ffffe83b ECX: 3fffefdd EDX: ffffe83b

Sep 22 15:33:41 Tower2 kernel: ESI: f82cd000 EDI: f02b38c4 EBP: c232df04 ESP: c232def4

Sep 22 15:33:41 Tower2 kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068

Sep 22 15:33:41 Tower2 kernel: Process emhttp (pid: 4784, ti=c232c000 task=f6c95b80 task.ti=c232c000)

Sep 22 15:33:41 Tower2 kernel: Stack:

Sep 22 15:33:41 Tower2 kernel: c232df38 f82c38a3 00000000 f02b1000 c232df4c c109d5f5 00000400 c232df3c

Sep 22 15:33:41 Tower2 kernel: <0> 00000000 00000400 00000000 00000400 b7884000 f6f1aa80 00000000 f6f1aa80

Sep 22 15:33:41 Tower2 kernel: <0> 00000400 f02b1000 00000001 f6f1aa80 c109d4ea fffffffb c232df70 c1099f72

Sep 22 15:33:41 Tower2 kernel: Call Trace:

Sep 22 15:33:41 Tower2 kernel: [] ? md_cmd_proc_read+0x0/0x54 [md_mod]

Sep 22 15:33:41 Tower2 kernel: [] ? proc_file_read+0x10b/0x22d

Sep 22 15:33:41 Tower2 kernel: [] ? proc_file_read+0x0/0x22d

Sep 22 15:33:41 Tower2 kernel: [] ? proc_reg_read+0x56/0x6a

Sep 22 15:33:41 Tower2 kernel: [] ? proc_reg_read+0x0/0x6a

Sep 22 15:33:41 Tower2 kernel: [] ? vfs_read+0x8a/0x114

Sep 22 15:33:41 Tower2 kernel: [] ? sys_read+0x3b/0x60

Sep 22 15:33:41 Tower2 kernel: [] ? syscall_call+0x7/0xb

Sep 22 15:33:41 Tower2 kernel: Code: 55 f0 e8 6a 32 e7 c8 8d 50 01 29 f2 39 d3 7c 0b 8b 45 0c 89 d3 c7 00 01 00 00 00 8b 45 f0 89 d9 81 c6 3c 8f 2c f8 c1 e9 02 89 38 a5 89 d9 83 e1 03 74 02 f3 a4 5a 89 d8 5b 5e 5f 5d c3 55 89

Sep 22 15:33:41 Tower2 kernel: EIP: [] md_cmd_proc_read+0x41/0x54 [md_mod] SS:ESP 0068:c232def4

Sep 22 15:33:41 Tower2 kernel: CR2: 00000000f82cd000

Sep 22 15:33:41 Tower2 kernel: ---[ end trace c37f40fe6e052df1 ]---

By the way, I belong to the same club  (this was on 5.0-beta2 on my newer server):

 

Well, Welcome to the club. 

 

If i recalled, this problem was reported since 4.5.3 and given that it took place at different platform and software release

while not many have this problem. this looks more like a memory corruption issue in software that is not that uncommon

in software development but not easy to fix and debug.

 

 

"You are one of selected few now in this "Oops club", refer to following link for information."

Wow, Thank you guys, I'm so proud 

 

"You are looking for a "raw" count greater than zero.  Your disks are fine."

JoeL - THANK-YOU!!! HUGE RELIEF

 

 

Thank you all so much for your fast accurate reposes on this. I'm very relived and extremely great-full for your help!

 

A