linux-kernel - Re: PROBLEM: I/O scheduler problem with an 8 SATA disks raid 5 under heavy load ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <DE29CFB4-18E5-4CA3-A44D-6AD46D1A122D@neuf.fr>
Date:	Wed, 20 Feb 2008 12:35:14 +0100
From:	Guillaume Laurès <guillaume-laures@...f.fr>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>
Subject: Re: PROBLEM: I/O scheduler problem with an 8 SATA disks raid 5 under heavy load  ?

Hello all,

A bit of update to this issue.

Switching the cabling of the most problematic drive with a new one  
didn't fix the issue.
I couldn't yet switch the power supply with a more powerful one.  
However I temporarily added a pci-e SATA host and another drive, the  
situation was just as bad, not worse ;-) This HBA just had 2 ports,  
so I couldn't swap it completely with the nvidia ports.

Just as a guess I added sata_nv.adma=0 and the problem completly  
disappeared for 4 weeks now. Removing it from cmdline just make it  
come back.

Unfortunately I'm running xen on this host so I don't think adma  
patches if any may be suitable to me, at least as long as something >  
2.6.20 doesn't come in gentoo for xen...

Regards,

GoM

Le 9 janv. 08 à 01:00, Robert Hancock a écrit :

>> So it seems to be either a cabling problem or a bug with sata_nv ?  
>> I'm running gentoo's 2.6.20-xen, and maybe my problem looks like  
>> the sata_nv/adma/samsung problems reports I can see on the net ?
>
> I don't think it's the same problem. In that case the controller  
> appears to indicate that it didn't even start processing the  
> command. In this case it's indicating that the command was sent to  
> the drive and is still waiting for it to indicate completion.
>
> It could be a cabling problem, yes. Also, are you sure your power  
> supply is able to handle the power draw of that many drives?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/