Date: Mon, 20 Aug 2007 10:03:49 -0400 From: Howard Goldstein <hg@queue.to> To: arne_woerner@yahoo.com Cc: freebsd-geom@freebsd.org Subject: Good workaround Re: graid5, 3 consumers, unaligned access Message-ID: <46C99F45.300@queue.to> In-Reply-To: <541513.41122.qm@web30315.mail.mud.yahoo.com> References: <541513.41122.qm@web30315.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Arne Wörner wrote: > --- Howard Goldstein <hg@queue.to> wrote: >> The twe driver has a design flaw that depends on malloc()ing bounce >> buffers when it's handed data not aligned on 512 byte boundaries. When >> malloc fails, the driver syslogs a unique error that only can come from >> > I had a look at that file (twe...c) and found that it is not 512 bytes but 64 > bytes (in 6.2R) and that it is about the virtual memory address and not about > the on-disk-offset... > > So it is not a GEOM problem... By the way I agree, as in the original message, I indicated this is a poorly designed driver. GEOM and graid5 seem to work flawlessly and efficiently on the other consumers. > > Maybe u could try to reduce the graid5 write cache by setting .maxwql and > .maxmem to something smaller. Reducing the write queue length does stop the complaining and that's definitely good. I don't see any performance hit looking at throughput with a naive dd-based throughput test and that's a bit of a relief. vm: Do you think twe(4) can be modified to avoid the malloc and bcopy and instead use the vm interface to remap it so it's on the 512 byte offset the stupid card wants to see? I'm not familiar with the pmap or vm facilities and whether they can do this or not.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46C99F45.300>