Re: WAPL/RAIDframe performance problems

["Martin S. Weber" <Ephaeton%gmx.net@localhost>]

On Sat, Nov 10, 2012 at 05:46:36PM +0100, Edgar Fuß wrote:
(...)
> 2. During the svn update, the machine partially locks up and fails to respond 
>    to NFS requests.

You need no raid for that. Use two different partitions. We used to have this
sucking. Then we had alternative disk prio schedulers. They solved the issue
somewhat. then came WAPL, and we're back to great performance on a single
partition, but sucky performance when writing to partition 1 while reading
from partition 2. Double the pain when the written to partition is a DOS one.

wd0 at atabus1 drive 0
wd0: <ST750LX003-1AC154>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 698 GB, 1453521 cyl, 16 head, 63 sec, 512 bytes/sect x 1465149168 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) 
(using DMA)


/dev/wd0a on / type ffs (log, local)
/dev/wd0g on /var type ffs (log, local)
/dev/wd0f on /usr type ffs (log, local)
/dev/wd0h on /home type ffs (log, local)
/dev/wd0i on /home/exchange type msdos (local)
/dev/wd0j on /space type ffs (log, local)

but simple copying an audacity project (i.e., gigs worth of data in 1MB chunks)
from my /home to my /space renders firefox unusable (i.e., it will likely only
start reacting again once the copy and/or move operation is finished across the
partitions/mountpoints).

In my absolutely non-empiric, subjective perception the best time
was when bufq-priocscan was no longer deemed experimental, performance
has decreased massively since then. uname doesn't matter. Things got
worse gradually ever since I ran 5.1/i386 (when it came out) until now,
where I'm on netbsd-6/amd64.

Regards,
-Martin