Re: Very slow file write/create operations

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 10 Apr 2026 12:56:35 +0200
    From:        Frank Wille <frank%phoenix.owl.de@localhost>
    Message-ID:  <d1f65d43-65e6-4293-bc9e-7b74c41815a2%phoenix.owl.de@localhost>

  | Would you expect NetBSD's software RAID instead of the HP's hardware 
  | RAID (ciss) to perform better?

No idea.   I know nothing about HP's RAID.

  | 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).

  | > Misalignment of raid stripes and filesystem blocks would be one of those,
  | How can I find that out?

No idea, something related to the raid configuration I'd guess.

Making sure everything is at a reasonable power of 2 multiple of
blocks (start & size) helps (no starting at block 63...), but you
need info on how the raid uses the drives to do it properly.

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

  | Ok, although the cp/rm times are quite different, umount shows similar 
  | durations, about 8 seconds, in the synchronous and async case.

That will be how long it takes to write (at least most of) the data.
The 20+ seconds (for each the cp, and rm) in the non-async case will
be the metadata write times for creating / removing the files.

Using wapbl instead of async should gain most of that time back, and
is safe to use, unlike async -- except for filesystems you're happy to
destroy and recreate after a crash ... I use async mounts for /usr/obj,
rather than a tmpfs, as an async filesys which is unmounted correctly,
as in an orderly shutdown, will be fine, and retain all its data, whereas
a tmpfs will not, but the speed of an async filesys is similar to tmpfs - in
practice everything just gets buffered in ram in both cases (data left in
the async filesys will eventually get written, but that's generally long
after whatever build was being done has finished).

  | 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.   Since you have the junk filesystem available temporarily
you could just do a dd of /dev/zero to the raw device (the same thing
you would mount - though be aware this will destroy the filesystem, which
must not be mounted) and see how fast that runs for a big enough number
of megabytes to be meaningful - that will test the raid's raw write speed.
On modern hardware (drives) I'd be hoping for something of the order of
60-100MBps for rotating rust (larger capacity tend to write faster), and
rather faster for SSD - though obviously it can't go any faster than the
connecting bus can deliver data.

Actual filesystem writes will never reach raw write speeds, as the data
isn't all being written in consecutive blocks, seeks are needed, which
slows things down.

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

So it does.   Unmounting is better (where possible) for benchmarking in
any case, as sync will write everything that's been modified, the umount
only the blocks on the filesystem being unmounted.   If the system is
quiet before & during the test, and a sync was done before it as well
as the one measured after, there is usually little difference though.

kre