| 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
| ||
|
Date: Mon, 18 Jun 2007 10:28:38 -0700 (PDT) From: david@...g.hm To: Brendan Conoboy <blc@...hat.com> cc: Neil Brown <neilb@...e.de>, Wakko Warner <wakko@...mx.eu.org>, linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org Subject: Re: limits on raid On Mon, 18 Jun 2007, Brendan Conoboy wrote: > david@...g.hm wrote: >> in my case it takes 2+ days to resync the array before I can do any >> performance testing with it. for some reason it's only doing the rebuild >> at ~5M/sec (even though I've increased the min and max rebuild speeds and >> a dd to the array seems to be ~44M/sec, even during the rebuild) > > With performance like that, it sounds like you're saturating a bus somewhere > along the line. If you're using scsi, for instance, it's very easy for a > long chain of drives to overwhelm a channel. You might also want to consider > some other RAID layouts like 1+0 or 5+0 depending upon your space vs. > reliability needs. I plan to test the different configurations. however, if I was saturating the bus with the reconstruct how can I fire off a dd if=/dev/zero of=/mnt/test and get ~45M/sec whild only slowing the reconstruct to ~4M/sec? I'm putting 10x as much data through the bus at that point, it would seem to proove that it's not the bus that's saturated. David Lang - 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/
Powered by blists - more mailing lists