Error creating Raid 5

[Jocko]

Hi b1gnas,

Yes,

When you degrade a raid, mdadm tries to synchronize again the raid once the raid has again all its members.

Note: this does not prevent you to use the NAS.

[Jocko]

Hi b1gnas,

We go to make some more additional tests about your ata port issue.

- test currently your write speed:
Please to stop ftp server and any other media servers, nfs server, ...

Code: Select all

time dd if=/dev/zero of=/share/1100/test.img bs=1MB count=1024

(this creates a 1GB file on your raid)

-in a putty window, do these command:

Code: Select all

echo 1 >/sys/block/sda/device/queue_depth
echo 1 >/sys/block/sdb/device/queue_depth
echo 1 >/sys/block/sdc/device/queue_depth
echo 1 >/sys/block/sdd/device/queue_depth
echo 1 >/sys/block/sde/device/queue_depth


- flush your dmesg

Code: Select all

dmesg -c

and do again write speed

Code: Select all

time dd if=/dev/zero of=/share/1100/test.img bs=1MB count=1024

Then post the two speed tests and look at if there are some errors in dmesg (without the option -c !!!) and also later

Note:fvdw has built a new kernel version to see if ata port error is still here with your Seagate disk. You will try it in a 2d test

[b1gnas]

Hi Jocko,

first speed test

Code: Select all

root@fvdwsl-base:/ # time dd if=/dev/zero of=/share/1100/test.img bs=1MB count=1024
1024+0 records in
1024+0 records out
real 0m 59.28s
user 0m 0.00s
sys 0m 21.77s


Second speed test

Code: Select all

root@fvdwsl-base:/ # echo 1 >/sys/block/sda/device/queue_depth
root@fvdwsl-base:/ # echo 1 >/sys/block/sdb/device/queue_depth
root@fvdwsl-base:/ # echo 1 >/sys/block/sdc/device/queue_depth
root@fvdwsl-base:/ # echo 1 >/sys/block/sdd/device/queue_depth
root@fvdwsl-base:/ # echo 1 >/sys/block/sde/device/queue_depth
root@fvdwsl-base:/ # time dd if=/dev/zero of=/share/1100/test.img bs=1MB count=1024
1024+0 records in
1024+0 records out
real 0m 53.70s
user 0m 0.02s
sys 0m 22.59s

No errors in dmesg

[Jocko]

Hi b1gnas,

so write speed is not really nice : I assume you get these value because your disks are a link up speed 1,5Gb/s instead of 3Gb/s.

No errors in dmesg

Now use your 5big1 and see later if there is still no error.

Can you post again

Code: Select all

lsscsi -l

[b1gnas]

Ok

Code: Select all

root@fvdwsl-base:/ # lsscsi -l
[0:0:0:0]    disk    ATA      ST1000DM003-1ER1 CC45  /dev/sde
  state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30
[1:0:0:0]    disk    ATA      ST1000DM003-1ER1 CC45  /dev/sdd
  state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30
[2:0:0:0]    disk    ATA      ST1000DM003-1ER1 CC45  /dev/sdc
  state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30
[3:0:0:0]    disk    ATA      ST1000DM003-1ER1 CC45  /dev/sdb
  state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30
[4:0:0:0]    disk    ATA      ST1000DM003-1ER1 CC45  /dev/sda
  state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30
root@fvdwsl-base:/ #


[b1gnas]

Still no errors on dmesg while trasferring files to the nas

[Jocko]

So at least with the queue_depth trick it seems that the ata errors disappear :thumbup

But as your disks are link up with a degraded speed, you have in all case a bad write speed before and after this trick. :?

Now we go to try the new kernel 3.18.21:
unzip the attached files in the share fvdw
make a folder 3.18.21 in /lib/modules

Code: Select all

mkdir /lib/modules/3.18.21

untar the file modules-31821-5big1-3.tar

Code: Select all

tar -xf /direct-usb/fvdw/modules-31821-5big1-3.tar -C /lib/modules/3.18.21

and check if /lib/modules/3.18.21 contains now the module files (*.so)

upgrade the kernel

Code: Select all

dd if=/direct-usb/fvdw/UIMAGE-31821-5BIG1-3 of=dev/sda6

reboot the nas

Code: Select all

sync;reboot

After rebooting post the dmesg content.

[b1gnas]

Mmmh leds are still blinking.... about 20 minutes from reboot

[fvdw]

Not a good sign. You can boot your nas again using the load external kernel action an choosing the 3.14.2 kernel for 5big1 (not the standalone kernel) It is in the 5big1 subfolder of the tfp directory. When it is alive thenvwe can restore the kernel to sda6

[Jocko]

That means that this version is bad. :crazy

To restore your NAS, save in tftp/5big1, the kernel image available here:http://plugout.net/viewtopic.php?f=30&t=2168&start=30#p18240 copy and unzip only uimage file (modules are still on the nas).
Stop the nas
use the fvdw-sl console ; use the option "load an external kernel" and then select the 3.14.2 uimage.

Then your nas should boot but the bad kernel version is still on /dev/sda6. I assume the kernel 3.14.2 image file is on the share fvdw:
do in putty

Code: Select all

dd if=/direct-usb/fvdw/UIMAGE-3142-5BIG1-1 of=/dev/sda6

To check if all is restored, reboot again the nas