Re: WAPL/RAIDframe performance problems

On Sat, Nov 10, 2012 at 05:46:36PM +0100, Edgar Fu=DF wrote:
(...)
> 2. During the svn update, the machine partially locks up and fails to r=
espond=20
>    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 is=
sue
somewhat. then came WAPL, and we're back to great performance on a single
partition, but sucky performance when writing to partition 1 while readin=
g
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 se=
ctors
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 c=
hunks)
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 acro=
ss 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