xfs
[Top] [All Lists]

Re: Pid: 8345, comm: rsync Not tainted 2.6.32.22intel #1

To: Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>
Subject: Re: Pid: 8345, comm: rsync Not tainted 2.6.32.22intel #1
From: Stefan Priebe - Profihost AG <s.priebe@xxxxxxxxxxxx>
Date: Tue, 26 Oct 2010 14:09:12 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20101026132505.6af29d5d@xxxxxxxxxxxxxxxxxxxx>
References: <4CC67450.9020602@xxxxxxxxxxxx> <20101026092205.086c0d89@xxxxxxxxxxxxxx> <4CC68249.7050409@xxxxxxxxxxxx> <20101026094111.48670eb7@xxxxxxxxxxxxxx> <4CC688FE.7010206@xxxxxxxxxxxx> <20101026130103.7cc43aec@xxxxxxxxxxxxxxxxxxxx> <4CC6B56B.7020007@xxxxxxxxxxxx> <20101026132505.6af29d5d@xxxxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9
Hi,

thanks for your suggestions.

> My other advices : generally don't use cfq scheduler with a RAID
> controller, it will defeat the whole purpose of RAID cache and command
> reordering abilities. Use noop, generally, and deepen the queue :
>
> echo "noop">  /sys/block/sdc/queue/scheduler
> echo 512>  /sys/block/sdc/queue/nr_requests

Is there a way to make this static to this disk?

> Don't hesitate to enlarge tremendously the read-ahead cache, too. I
> generally use about 512 to 1024 sectors  per drive as a rule of the
> thumb, so a 4 drives array will use 2048 to 4096 :
>
> blockdev --setra 4096 /dev/sdc
Is there also a way to make this static?

> You should see a 100% write/read speed improvement with these
> parameters.
That would be great.


Thanks Stefan

Am 26.10.2010 13:25, schrieb Emmanuel Florac:
Le Tue, 26 Oct 2010 13:03:07 +0200
Stefan Priebe - Profihost AG<s.priebe@xxxxxxxxxxxx>  écrivait:

it is a 9650SE-8LPML with Firmware: FE9X 3.06.00.003.

Augh, this firmware is antique :) The latest is 4.10.xx.xx. Anyway,
don't use firmware before 3.08.xx.xx, there were some nasty bugs.

So you mean i should upgrade to 4.x Firmware?

Definitely. It will much improve performances, too. Simply download the
firmware file, extract it, and flash the controller with tw_cli :

tw_cli /cXX update fw=prom0006.img

(the firmware is always in the prom00xx.img file).

Do i then have to do a
filesystem repair? Or just wait if the error accours again?

No, the filesystem will be fine. However you should start a RAID scrub
with

tw_cli /cXX/uXX start verify

This will rebuild the parity with the new 4.X format (faster writes)
and help detect any hardware fault.

My other advices : generally don't use cfq scheduler with a RAID
controller, it will defeat the whole purpose of RAID cache and command
reordering abilities. Use noop, generally, and deepen the queue :

echo "noop">  /sys/block/sdc/queue/scheduler
echo 512>  /sys/block/sdc/queue/nr_requests

Don't hesitate to enlarge tremendously the read-ahead cache, too. I
generally use about 512 to 1024 sectors  per drive as a rule of the
thumb, so a 4 drives array will use 2048 to 4096 :

blockdev --setra 4096 /dev/sdc

You should see a 100% write/read speed improvement with these
parameters.


<Prev in Thread] Current Thread [Next in Thread>