ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load
Guido Falsi
mad at madpilot.net
Mon Feb 8 16:17:40 UTC 2010
On Mon, Feb 08, 2010 at 06:51:47AM -0800, Jeremy Chadwick wrote:
> On Mon, Feb 08, 2010 at 03:33:29PM +0100, Guido Falsi wrote:
> >
> > 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).
>
> 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've seen Solaris 10 systems which behave the same way, and others which
> don't. I don't know what causes things to start behaving this way.
Thank you for the explanation. I in fact see the same problem with the
legacy ata driver.
I see this is something not trivial to fix, so I don't want to put too
much burden on the pople who brought us zfs, which is anyway a great
thing!
Anyway the sluggish responsiveness of the system during these bursts is
a problem for desktop use. I see that ZFS is mainly a server oriented
FS, but this should be addressed sometime in the future I think.
>
> > BTW there's another thing that shows up on this machine. Lately, this
> > too after putting the option ATA_CAM in the kernel, during boot there is
> > a long pause(exactly one minute, as the message below states) in this
> > point of the dmesg:
>
> This should probably be discussed in a different thread.
I'll follow your suggestion and post a new thread about this.
Thank you again!
--
Guido Falsi <mad at madpilot.net>
More information about the freebsd-stable
mailing list