4.8 ffs_dirpref problem

[Bruce Evans]

On Tue, 21 Oct 2003, David Rhodus wrote:

> I have one question, why do you have softupdates turned off ?
> With softupdates it could be possible to get faster writes than using
> an async mount.

Soft updates have never been faster than async for me, and in recent
simple tests (copying /usr/src) they have become significantly slower
than even ordinary (non-soft-update, non-sync, non-async mounts):

2002/05/30
----------
ffs-16384-2048-1:
tarcp /e src:                278.82 real         0.76 user        14.99 sys
ffs-16384-2048-as-1:
tarcp /e src:                180.39 real         0.73 user        13.69 sys
ffs-16384-2048-su-1:
tarcp /e src:                181.98 real         0.69 user        13.81 sys

2003/09/23
----------
ffs-16384-02048-1:
tarcp /f src:                 68.66 real         0.82 user        13.81 sys
ffs-16384-02048-as-1:
tarcp /f src:                 41.09 real         0.83 user        11.25 sys
ffs-16384-02048-su-1:
tarcp /f src:                111.62 real         0.82 user        11.49 sys

ffs-16384-02048-1 means ffs with a block size of 16384, a fragment size of
2048, soft updates and ffs^WUFS1, etc. (there was no ffs2 at the time of the
old benchmark and the "-1" in it actually meant doreallocblks=1).

The machine is Athlon 1600XP overclocked running -current at the time with
only the following major changes:
- main memory increased from 512MB to 1024MB.  This increases the relevance
  of the test as a write benchmark by giving enough memory to keep the
  source of the copy cached.
- target disk changed from an IBM-DTLA-307030 (30MB ATA) to an
  IC35L060AVVA07-0 (60MB ATA).  The file system had size 13GB in both cases
  and was at a similar offset in the disks; this puts it closer to the outer
  tracks on the larger disk so accesses to it were faster (approx. 40MB/sec
  vs 29 MB/sec)
Most of the real times were improved significantly by the hardware changes,
but for some reason soft updates didn't benefit as much as the others.  This
behaviour is not dependent on the block/frag sizes or ffs1/2.

Bruce