Re: Very slow file write/create operations

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

    Date:        Wed, 8 Apr 2026 16:11:43 +0200
    From:        Frank Wille <frank%phoenix.owl.de@localhost>
    Message-ID:  <71eaa02a-442a-40d0-ad1f-732f5af7bb39%phoenix.owl.de@localhost>

  | As I now understand synchronous writes are the default,

synchronous metadata writes, not data.

  | unless I specify -o async.

Or -o log, as you discovered.

  | 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.
Misalignment of raid stripes and filesystem blocks would be one of those,
another would be the amount of cache memory in the raid controller,
to allow updates of small numbers of blocks spread throughout the
filesystem, without constantly needing to re-read the raid stripes.

I use default mounts (not -o log, that tends to get to be problematic
with very large filesystems) and definitely not -o async (that's not
suitable for anything with any data you want to keep) with raidframe,
without any particular problems (though most of the files are large, not
lots of small ones).

  | Anyway, I didn't make the -o async test yet, because it requires adding 
  | more disks, or making the swap partition smaller.

With 128GB ram, unless you are running something very big, I doubt that
you really need swap - I have "only" 64GB, and my system has never used
a sector of the swap space (crash dumps aside) that I am aware of - I don't
do pkgsrc bulk builds though (I do do highly parallel NetBSD builds).

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.

  | So I added the "log" option in /etc/fstab, rebooted and repeated the test:
  | That's what I would expect! The extreme delay is gone. I can even add a 
  | sync and it's still factor 20:
  |
  | # time cp -Rp /etc /root; time sync
  |          0.05 real         0.00 user         0.04 sys
  |          1.14 real         0.00 user         0.00 sys
  | # time rm -rf /root/etc; time sync
  |          0.01 real         0.00 user         0.01 sys
  |          0.26 real         0.00 user         0.00 sys

"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.   In ancient
unix, 3 sync's would guarantee the output was flushed (and yes, it was
guaranteed, unrelated to all the tall tales about why 3 was magic), but
I am fairly sure that's no longer the case.   The only way to reliably
know that the data has been flushed, is to umount the filesystem - which
is kind of hard to do if everything is just on /.

Almost certainly all you have timed there is a copy into the buffer cache,
(which isn't really what it is any more, but never mind) probably with
almost no i/o actually performed (yet).   The real time measured for sync
is (I am guessing, I haven't looked) probably how long it is taking to
hunt for the blocks that need writing, perhaps along with a small number
of actual output operations.

kre