Re: Very slow file write/create operations

[Frank Wille <frank%phoenix.owl.de@localhost>]

Robert Elz wrote:

>    | Then the negative effect of synchronous writes is especially
>    | visible with RAID configurations?
>
> Not necessarily - it probably depends upon the raid implementation
> (and the underlying drives) - and also the filesystem configuration
> and layout.   There are lots of things which can cause slowdowns.

Ok.

Would you expect NetBSD's software RAID instead of the HP's hardware 
RAID (ciss) to perform better? Do you have recommendations for tuning 
the filesystem?

At least I'm getting similar performance to the old server now, which 
makes me happy.


> Misalignment of raid stripes and filesystem blocks would be one of those,

How can I find that out?


> another would be the amount of cache memory in the raid controller,

HP SmartArray P420i - probably 512MB cache.


> But as your WAPBL test showed that the delays you are experiencing are
> almost certainly all the sync metadata writes (exactly what WAPBL is
> designed to eliminate), there is no real point in an async test any more,
> though a test where you write the data, then umount the filesystem, would
> show the real write speed.

Ok, I changed my disklabel to transform the swap-partition b into a 
4.2BSD partition e:

# disklabel sd0
[...]
 a: 708337664      2048     4.2BSD      0     0     0  # (Cyl.      0*- 
 23540*)
 c: 976701757      2048     unused      0     0        # (Cyl.      0*- 
 32459*)
 d: 976703805         0     unused      0     0        # (Cyl.      0 - 
 32459*)
 e: 268364093 708339712     4.2BSD      0     0     0  # (Cyl.  23540*- 
 32459*)

Then I repeated the test, including the umount:

# mount /dev/sd0e /mnt
# time cp -Rp /etc /mnt/; time umount /mnt

real    0m26.328s
user    0m0.000s
sys     0m0.067s

real    0m8.346s
user    0m0.000s
sys     0m0.012s
# mount /dev/sd0e /mnt
# time rm -rf /mnt/etc; time umount /mnt

real    0m20.222s
user    0m0.000s
sys     0m0.019s

real    0m0.171s
user    0m0.001s
sys     0m0.001s

And again with async option:

bash-5.3# mount -o async /dev/sd0e /mnt
bash-5.3# time cp -Rp /etc /mnt/; time umount /mnt

real    0m0.115s
user    0m0.000s
sys     0m0.048s

real    0m8.737s
user    0m0.000s
sys     0m0.018s
bash-5.3# mount -o async /dev/sd0e /mnt
bash-5.3# time rm -rf /mnt/etc; time umount /mnt

real    0m0.125s
user    0m0.000s
sys     0m0.009s

real    0m0.115s
user    0m0.001s
sys     0m0.001s

Ok, although the cp/rm times are quite different, umount shows similar 
durations, about 8 seconds, in the synchronous and async case. So you 
are right. Not sure if 8 seconds is to be expected for such a RAID.


> "time sync" is a waste of time (pun intended) - sync just starts the
> process of writing data, it doesn't wait for it to finish.

I would hope this is obsolete. The man page for the sync(2) system call 
states in its last sentence:

"In NetBSD, sync() does not return until all buffers have been written."

--
Frank Wille