Date: Thu, 04 Jul 2013 10:30:17 -0400 From: Travis Mikalson <bofh@terranova.net> To: freebsd-fs@FreeBSD.org Subject: Re: Report: ZFS deadlock in 9-STABLE Message-ID: <51D586F9.7060508@terranova.net> In-Reply-To: <51D5804B.7090702@FreeBSD.org> References: <51D45401.5050801@terranova.net> <51D5776F.5060101@FreeBSD.org> <51D57C19.1080906@terranova.net> <51D5804B.7090702@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > on 04/07/2013 16:43 Travis Mikalson said the following: >> Yes, that helpful article is where I got the run-down on how best to >> report what was going on here. I still believe this is an actual >> deadlock bug and not a storage layer issue. >> >> I have not seen any indications of any problems with my storage layer. >> You'd think there would be some scary-looking complaint on the console >> during one of these deadlocks if it had suddenly lost the capability to >> communicate with most or all the disks, but I've deadlocked at least 10 >> times now in 2013 and never anything of the sort. Thanks to IPMI, I have >> actually viewed the console each time it has happened. > > Well, I do consider GEOM, CAM, drivers to be parts of the storage layer. > In other words, everything below ZFS. Ah, I believe I understand. It's not necessarily a hardware issue (which is what I took away from the original verbage), the deadlock may have occurred in other parts of the storage layer. FWIW, my simple UFS compact flash that I boot from also becomes inaccessible during these deadlocks. All UFS and ZFS storage goes dead simultaneously. If it were purely a ZFS issue, I suppose one might expect to still be able to read from their UFS filesystem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51D586F9.7060508>