ufs+softupdates / consistency

Bruce Evans bde at zeta.org.au
Thu Jan 27 09:39:23 PST 2005


On Wed, 26 Jan 2005, Arne W=F6rner wrote:

> --- Xin LI <delphij at frontfree.net> wrote:
> > =E5=9C=A8 2005-01-26=E4=B8=89=E7=9A=84 17:42 -0800=EF=BC=8CArne WXrner=
=E5=86=99=E9=81=93=EF=BC=9A
> > > Can somebody explain me, why write speed is so much slower
> > > than read speed (even with hard disc write cache)?
> >
> > This is common case caused by physical constraints I guess :-)

There should be little difference for most disks.  Maybe you don't
actually have the write cache enabled.  Some firmware is rumoured
mishandle the wc flag.

> > > I tried an UFS1 file system mounted async for another test.
> > > And the write speed was still about 5 Mbyte/sec.
> >
> > Well, I haven't benchmarked it by myself, however, the author of
> > SoftUpdates claims that the benchmark should be 95% or so as you
> > async mount a UFS file system.

For me, it used to be about 1.5 times slower for the benchmark of
writing a copy of /usr/src, but it is now 3 times slower for this,
and it is even slightly slower than soft updates without async.

> > BTW: I think 5MB/s of write
> > speed is somewhat too slow for an IDE device, you may want to
> > check the cable, etc.
> >
> Hmm. I tried a "dd if=3D/dev/zero of=3Da bs=3D64k count=3D1000 ; sync"
> with KNOPPIX and the same slice/cable and ext3fs (mkfs with
> defaults) and it was about 4 times faster than FreeBSD R5.3.

A count of 1000 is far too small for this benchmark.  FreeBSD will
start writing data after accumulating at most 128K (64K?), but
Linux (at least old versions) may cache everything.  The "sync"
part of the above command doesn't actually sync the data, at least
under FreeBSD where sync just starts syncing of the data.

The speed of a correct version of this benchmark doesn't depend much
on either asyncness or soft-updateness.  Asyncness in FreeBSD mainly
affects metadata, but the above writes mainly data.

> Furthermore the read speed is about 25Mbyte/sec, so that the cable
> seems to be ok.

I get 24MB/sec without soft updates or async, 25MB/sec without soft
updates but with async, to separate and almost full file systems on
an old disk than can only do 36MB max.  FreeBSD normally does well
on this benchmark.  24MB/sec is very good considering that the file
systems are old and full (and thus fragmented).  The performance for
many small files can be much worse (10% of the disk bandwidth is
too common).  This is where non-sync metadata updates can help a
lot.

> Funnily my other hard disc (SAMSUNG SP1604N), which uses the same
> cable, is much faster:
>  write
>   (bs=3D64k count=3D1000 if=3D/dev/zero):
>   appr. 48Mbyte/sec
>  read
>   (bs=3D64k count=3D3975 if=3D<another file>):
>   appr. 38Mbyte/sec (???????????)
> I do not understand this different behaviour... *sniff*

This is normal behaviour.  It sure looks like the other disk doesn't
handle writes very well.  Write caching shouldn't affect this much.
FreeBSD should write blocks with size mostly 64K or 128K no matter
what the dd block size is, and it is up to the disk to handle such
sizes well.  Use iostat to see block sizes related to those seen
by the disk.

Bruce


More information about the freebsd-fs mailing list