Good workaround Re: graid5, 3 consumers, unaligned access

[Howard Goldstein]

Arne Wörner wrote:
> --- Howard Goldstein <hg at 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.