zio_done panic in 10.3
avg at FreeBSD.org
Wed Nov 22 15:29:07 UTC 2017
On 22/11/2017 16:40, Youzhong Yang wrote:
> Hi Andriy,
> This is nice! I am 100% sure it's exactly the same issue I experienced and then
> reported to illumos mailing list. In all the crash dumps zio->io_done =
> l2arc_read_done, so I thought the crash must be related to L2ARC. Once I set
> secondarycache=metadata, the frequency of crash went from one per 2 days down to
> one per week. I've been puzzled by what could have caused a zio being destroyed
> while there's still child zio. Your explanation definitely makes sense!
Oh, I now recall seeing your report:
I remember that it raised my interest, but then I forgot about it and didn't
correlate it with the latest reports.
> By the way, is there a FreeBSD bug report or an illumos bug number tracking this
> issue? I would be more than happy to create one if needed, and also test your
> potential fix here in our environment.
I am not aware of any existing bug report.
It would be great if you could open one [ or two :-) ]
If you open an illumos issue, please also add George Wilson as a watcher.
I think that George is also interested in fixing this issue and he knows the
relevant code better than me.
> On Tue, Nov 21, 2017 at 3:46 PM, Andriy Gapon <avg at freebsd.org
> <mailto:avg at freebsd.org>> wrote:
> On 21/11/2017 21:30, Shiva Bhanujan wrote:
> > it did get compressed to 0.5G - still too big to send via email. I did send some more debug information by running kgdb on the core file to Andriy, and I'm waiting for any analysis that he might provide.
> Yes, kgdb-over-email turned out to be a far more efficient compression :-)
> I already have an analysis based on the information provided by Shiva and by
> another user who has the same problem and contacted me privately.
> I am discussing possible ways to fix the problem with George Wilson who was very
> kind to double-check the analysis, complete it and suggest possible fixes.
> A short version is that dbuf_prefetch and dbuf_prefetch_indirect_done functions
> chain new zio-s under the same parent zio (a completion of one child zio may
> create another child zio). They do it using arc_read which can create either a
> logical zio in most cases or a vdev zio for a read from a cache device (2arc).
> zio_done() has a check for the completion of a parent zio's children but that
> check is not completely safe and can be broken by the pattern that dbuf_prefetch
> can create. So, under some specific circumstances the parent zio may complete
> and get destroyed while there is a child zio.
> I believe this problem to be rather rare, but there could be configurations and
> workloads where it's triggered more often.
> The problem does not happen if there are no cache devices.
> > From: Conrad Meyer [cem at freebsd.org <mailto:cem at freebsd.org>]
> > Sent: Tuesday, November 21, 2017 9:04 AM
> > To: Shiva Bhanujan
> > Cc: Andriy Gapon; freebsd-fs at freebsd.org <mailto:freebsd-fs at freebsd.org>
> > Subject: Re: zio_done panic in 10.3
> > Have you tried compressing it with e.g. xz or zstd?
> > --
> Andriy Gapon
> freebsd-fs at freebsd.org <mailto:freebsd-fs at freebsd.org> mailing list
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org
> <mailto:freebsd-fs-unsubscribe at freebsd.org>"
More information about the freebsd-fs