Date: Tue, 03 Oct 2006 13:14:09 +0200 From: Ian FREISLICH <if@hetzner.co.za> To: Chris Hedley <cbh-freebsd-current@groups.chrishedley.com> Cc: current@freebsd.org Subject: Re: aac0: COMMAND 0xffffffffxxxxxxxx TIMEOUT AFTER xx SECONDS Message-ID: <E1GUiDx-000ElP-Il@hetzner.co.za> In-Reply-To: Message from Chris Hedley <cbh-freebsd-current@groups.chrishedley.com> of "Tue, 03 Oct 2006 09:02:33 %2B0100." <20061003084813.S1531@teapot.cbhnet>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Hedley wrote: > On Tue, 3 Oct 2006, Ian FREISLICH wrote: > >> I've been having a look at some reviews, but unfortunately few of them > >> make it clear whether or not the hard drives' cache is set to write back > >> or write through. Needless to say, I'm not desperately enthusiastic about > >> combining a RAID controller with write back caching, but I suspect that a > >> lot of controllers are heavily dependent on it being enabled to attain > >> their performance: it seems that my 2410SA's rather dismal 3-6 & 30-40MB/s > >> respective RAID5 write & read speeds would increase dramatically were I to > >> use write-back, but I'm not going there... I guess my point is that I > >> really don't want to find myself with another dog if I buy something with > >> apparently superior performance if it's completely reliant on on-disc > >> write back caching being enabled. > > > > I'm guessing this is because this controller has no read cache and > > no battery for it's write cache: > > > > AAC0> conta sho cache 0 > > Executing: container show cache 0 > > > > Global Container Read Cache Size : 0 > > Global Container Write Cache Size : 16203776 > > > > Read Cache Setting : ENABLE > > Write Cache Setting : ENABLE WHEN PROTECTED > > Write Cache Status : Inactive, battery not present > > > > If you're happy using the controller's write cache without battery > > backup, you can turn it on quite easily: > > > > container set cache /unprotected 0 > > Thanks for the reply, Ian. > > I gave your suggestion a try just to see what difference it made, but > I was only seeing marginal (if any) improvement with the transfer > rates, which I thought was rather strange: reads are still in the > order of 30-40 MB/s and writes still under 8 MB/s, to both RAID5 and > RAID10 containers, which I find rather disappointing performance-wise. I'd not expect any change on read performance since there is no read cache on this controller. Also, if you write a file that's larger than the controller cache (16MB) you'll not see an improvement. Is your disk transfer profile really always large writes? I'd expect it to be on average much smaller but I'm not sure how to draw these stats. I'm sure this setting will be a net win. If you're really after perhaps you'd rather look at LVD SCSI RAID solutions. I remember getting in excess of 150MB/s or so using a multiple channel RAID controller and a bunch of 10000rpm disks many years ago. SCSI on disk cache is, I'm told a diferent beast to IDE on disk cache (which lies). Besides SCSI actually performs under load. > I can't complain about how well it rebuilds, I just wish it didn't > take so long! Mine's done several due to a bad connection to one of > its discs and has recovered every time; the only niggle is that it > takes between 6 and 12 hours to recover the disc on a config with > 4x250GB units containing two small RAID-10 containers and one large > RAID-5. I'm not sure if that's really what I should be expecting; > I've heard other controllers rebuilding the likes of Raptors in about > half an hour, so I'd've thought I might expect perhaps no more than > two or three hours, albeit a rather simplistic assumption. You might be able change how much time the controller spends rebuilding by using the io_delay command on the container. I know a slow rebuild is a bit frustrating, but if I were after disk performance, I'd not want a rebuild to eat significantly into that. Ian -- Ian Freislich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1GUiDx-000ElP-Il>