Re: Very slow file write/create operations

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

Robert Elz <kre%munnari.OZ.AU@localhost> wrote:

> | Do you have recommendations for tuning the filesystem?
>
> Ideally the file system block size matches the raid stripe size, so
> a block write doesn't require reading from the drive to complete the
> data in the stripe - but whether that matters much depends upon just
> how the raid is implemented. Certainly you don't want to split
> blocks between multiple stripes, and you want the stripes to be
> multiples of the drive hardware blocksize (not the blocksize exposed by
> the drive for addressing purposes, but the one it actually uses).

Makes sense. Then I just have to find that information, besides a
way to tune it.


> | Not sure if 8 seconds is to be expected for such a RAID.
>
> It depends just how much data is in your /etc - use du and find out
> how many blocks it occupies, and work out the actual write speed from
> that. Mine is of the order of 16MB, 8 secs to write 16MB (2MBps) would
> be quite slow.

Yes. It's only 14MB on my freshly installed system.

Did the same test on my old server with a software RAID partition,
and umount takes just 1.3 seconds.

Then I took the chance to compare hardware RAID with software RAID
speed on my old server (which has an older HP Smart Array generation):
the hardware RAID only seems a few percent faster than the software
RAID for copying and syncing /etc.

So, for some reason this is still faster than the new server.


> Since you have the junk filesystem available temporarily
> you could just do a dd of /dev/zero to the raw device

I had already changed my disklabel again. So I disabled swap and
wrote to /dev/rsd0b instead:

# dd if=/dev/zero of=/dev/rsd0b bs=1m count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 17.348 secs (61894271 bytes/sec)

This looks normal. So the problem is not in ciss(4)?

-- 
Frank Wille