Date: Tue, 24 Apr 2007 13:53:40 +0200 From: Ollivier Robert <roberto@keltia.freenix.fr> To: freebsd-current@freebsd.org, current@freebsd.org, William Josephson <freebsd-current@morphisms.net> Subject: Re: ATA FLUSHCACHE Message-ID: <20070424115340.GA2172@keltia.freenix.fr> In-Reply-To: <200704241942.40874.doconnor@gsoft.com.au> References: <20070424051420.GA84831@mero.morphisms.net> <200704241554.12605.doconnor@gsoft.com.au> <20070424084409.GA98777@keltia.freenix.fr> <200704241942.40874.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
According to Daniel O'Connor: > Hmm, it is a non fatal error for gjournal, I'm kind of surprised it's a > fatal one for ZFS.. It is not a fatal one for ZFS per se. If I use ZFS in a configuration that does not require writing on two disks (a gconcat-like configuration), it works and FLUSHCACHE timeouts are not fatal. As soon as I try to get it working in a more disk-intensive (raidz in that case) way, it blows up with a panic. It seems to point to a flaw in the ata driver which may not be managing semaphores/mutex correctly or maybe in the way it uses UMA zones (the panic starts there). ZFS is only a very reproductible way of triggering the problem. > If the cache flush really failed (eg due to a stuffed disk) then there > really is a problem, but IMO it is likely this is going to be caught by > a read or a write operation very soon. Yes. > If it is a transient error then panicing seems to be about the worse > response :) Agreed. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006 i386
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070424115340.GA2172>