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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46756C6E.1070106@tmr.com>
Date:	Sun, 17 Jun 2007 13:16:30 -0400
From:	Bill Davidsen <davidsen@....com>
To:	david@...g.hm
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

david@...g.hm wrote:
> On Sat, 16 Jun 2007, Neil Brown wrote:
>
>> It would be possible to have a 'this is not initialised' flag on the
>> array, and if that is not set, always do a reconstruct-write rather
>> than a read-modify-write.  But the first time you have an unclean
>> shutdown you are going to resync all the parity anyway (unless you
>> have a bitmap....) so you may as well resync at the start.
>>
>> And why is it such a big deal anyway?  The initial resync doesn't stop
>> you from using the array.  I guess if you wanted to put an array into
>> production instantly and couldn't afford any slowdown due to resync,
>> then you might want to skip the initial resync.... but is that really
>> likely?
>
> 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)
>
> I want to test several configurations, from a 45 disk raid6 to a 45 
> disk raid0. at 2-3 days per test (or longer, depending on the tests) 
> this becomes a very slow process.
>
I've been doing stuff like this, but I just build the array on a 
partition per drive so the init is livable. For the stuff I'm doing a 
total of 500-100GB is ample to do performance testing.
> also, when a rebuild is slow enough (and has enough of a performance 
> impact) it's not uncommon to want to operate in degraded mode just 
> long enought oget to a maintinance window and then recreate the array 
> and reload from backup.

-- 
bill davidsen <davidsen@....com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ