ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load

[Fabian Keil]

Jeremy Chadwick <freebsd at jdc.parodius.com> wrote:

> On Mon, Feb 08, 2010 at 03:33:29PM +0100, Guido Falsi wrote:

> > I'm seeing this problem on my machine at work. It's an HP DC 7800,
> > mounts an ich9 chipset(not ahci capable). I'm attaching the dmesg.
> > 
> > I noticed this in the past, but it got evident(and very annoying)
> > while recompiling many ports today after the jpeg-8 update.
> > 
> > It looks like it freezes the system for the second or two it takes
> > to flush buffers to disk when there are big outputs. This happens
> > when decompressiong big distfiles, mainly. The openoffice port
> > triggers this almost continuosly every few seconds during compilation.
> > I've also seen this when working with big files(for example graphic
> > images in uncompressed formats).
> > 
> > It gets very annoying and I don't remember this happening before
> > activating the ATA_CAM flag. There was some slowdown with big disk
> > access, but not a total freeze.
> 
> This happens without ATA_CAM (e.g. using ataahci(4) or any other
> controller driver).

Indeed.

> The behaviour you're describing (bursty heavy disk I/O that stalls the
> subsystem) is pretty much the norm on all FreeBSD systems I've seen with
> ZFS.  When it starts happening, it's easy to notice/follow using "zpool
> iostat 1" or "gstat -I500ms".  Lots of I/O will happen (read or write)
> and the ARC is essentially being thrashed -- said utilities won't show
> any I/O counters incrementing until some threshold is reached, where
> you'll see a massive amount of I/O reported, during which time the
> system is sluggish (beyond acceptable levels, IMHO).  A few seconds
> later, the I/O counters start reporting 0 as the ARC gets used, then
> a few seconds massive I/O, rinse lather repeat.

I experienced what I think is the same problem. ZFS's bulk disk flushes
caused vlc to occasionally stutter when viewing a DVD rip from disk while
ripping a DVD at the same time.

My workaround is to put "vfs.zfs.txg.timeout=3" in /boot/loader.conf.
I think I read about this on zfs-discuss at . I assume on faster systems
one can use a higher value.

I'm currently updating the jpeg dependencies, too:

fk at r500 ~ $zpool iostat 1
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         176G  52.1G     22     40  1.40M  1.85M
tank         176G  52.1G     73      0  9.24M      0
tank         176G  52.1G     73      0  9.05M      0
tank         176G  52.1G     42    176  5.12M  11.3M
tank         176G  52.1G     68      0  8.62M      0
tank         176G  52.1G     67      0  8.43M      0
tank         176G  52.1G     57    106  7.11M  9.54M
tank         176G  52.1G     75      0  9.50M      0
tank         176G  52.1G     76      0  9.62M      0
tank         176G  52.1G     46    167  5.74M  11.7M
tank         176G  52.1G     79      0  9.99M      0
tank         176G  52.1G     81      0  10.2M      0
tank         176G  52.1G     43    164  5.43M  11.7M
tank         176G  52.1G     71      0  9.00M      0
tank         176G  52.1G     61     39  7.74M  5.00M
tank         176G  52.1G     46    111  5.74M  9.17M
tank         176G  52.1G     71      0  8.99M      0
tank         176G  52.1G     80      0  10.1M      0
tank         176G  52.1G     47    113  5.87M  9.68M
tank         176G  52.1G     70      0  8.87M      0
tank         176G  52.1G     78      0  9.80M      0
tank         176G  52.1G     42    164  5.24M  11.3M
tank         176G  52.1G     76      0  9.62M      0
tank         176G  52.1G     79      0  9.99M      0
tank         176G  52.1G     49    153  6.11M  10.8M
tank         176G  52.1G     72      0  9.12M      0

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100208/3be2ab4a/signature.pgp