Date: Tue, 18 Mar 2025 17:04:12 -0700 From: Xin LI <delphij@gmail.com> To: Seyed Pouria Mousavizadeh Tehrani <info@spmzt.net> Cc: dch@skunkwerks.at, freebsd-current@freebsd.org, mav@freebsd.org Subject: Re: zap_increment panic on specific zpool Message-ID: <CAGMYy3vBuZPj=maUfToXLH_3JP2nRO3-MuNT%2BGikFpKea5d5%2BA@mail.gmail.com> In-Reply-To: <0f55b357-2a9f-4b04-bd12-a0afe92da5d7@spmzt.net> References: <887C8BE0-9670-4892-9B60-9CA09675D40C@spmzt.net> <d783ac35-1bb5-43cf-a426-ecfec54f14b4@app.fastmail.com> <0f55b357-2a9f-4b04-bd12-a0afe92da5d7@spmzt.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Tue, Mar 18, 2025 at 2:40 PM Seyed Pouria Mousavizadeh Tehrani < info@spmzt.net> wrote: > I created another pool and backed up all my data using rsync, which avoids > block level cloning. It's working! > This probably has nothing to do with block cloning. The assertion was that zap_increment() succeeded (0), while EIO (5) was returned instead. This is likely the result of data corruption with correct checksums (in that case it's likely that you would see ECKSUM=122). When this happens, it's usually a permanent damage, the pool should still be read-only importable but you can't revive it to read-write state. Common causes of this would be a permanent damage which could be the result of a memory corruption (could be a bug in the kernel, or more usually, faulty memory that was not detected or panicked your system earlier). > Should I create a PR for this issue on FreeBSD or OpenZFS github > repository? > If you have a way to reliably trigger the issue please do file a FreeBSD PR or open an issue at OpenZFS as it would be very useful. Otherwise, it's likely to be faulty memory and there is not a lot that can be done from software. > > On 3/18/25 16:57, Dave Cottlehuber wrote: > > On Tue, 18 Mar 2025, at 12:35, Seyed Pouria Mousavizadeh Tehrani wrote: > > Hi, > > I was working on my desktop when it suddenly panicked, and Now, I'm > unable to boot into multi-user mode anymore. Additionally, in single > user-mode with my bpool, whenever I execute the "zpool import it > rpool", the panic occurs shortly after. > > My kdb backtrace log is attached to this url.<https://ibb.co/v6d4Kr7K>; <https://ibb.co/v6d4Kr7K>; > > I'm using FreeBSD 15.0-CURRENT main-n275975-5963423232e8. > > This looks like an assert; you may be able to boot again using > either a RELEASE if your zpool hasn't been upgraded past that > point, or a GENERIC-NODEBUG from CURRENT. This would at least get > you working, but it won't fix the underlying cause. > > hope it helps, > A+ > Dave > > > -- > Seyed Pouria Mousavizadeh Tehrani > Hoopad Cloud (AS214145) > > [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Mar 18, 2025 at 2:40 PM Seyed Pouria Mousavizadeh Tehrani <<a href="mailto:info@spmzt.net">info@spmzt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2107036440430642687"><u></u> <div> <p>I created another pool and backed up all my data using rsync, which avoids block level cloning. It's working!<br></p></div></div></blockquote><div><br></div><div><span class="gmail_default" style="font-family:monospace,monospace">This probably has nothing to do with block cloning.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">The assertion was that zap_increment() succeeded (0), while EIO (5) was returned instead. This is likely the result of data corruption with correct checksums (in that case it's likely that you would see ECKSUM=122). When this happens, it's usually a permanent damage, the pool should still be read-only importable but you can't revive it to read-write state. Common causes of this would be a permanent damage which could be the result of a memory corruption (could be a bug in the kernel, or more usually, faulty memory that was not detected or panicked your system earlier).</span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2107036440430642687"><div><p>Should I create a PR for this issue on FreeBSD or OpenZFS github repository?</p></div></div></blockquote><div><span class="gmail_default" style="font-family:monospace,monospace">If you have a way to reliably trigger the issue please do file a FreeBSD PR or open an issue at OpenZFS as it would be very useful. Otherwise, it's likely to be faulty memory and there is not a lot that can be done from software.</span><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2107036440430642687"><div> <p><br> </p> <div>On 3/18/25 16:57, Dave Cottlehuber wrote:<br> </div> <blockquote type="cite"> <pre>On Tue, 18 Mar 2025, at 12:35, Seyed Pouria Mousavizadeh Tehrani wrote: </pre> <blockquote type="cite"> <pre>Hi, I was working on my desktop when it suddenly panicked, and Now, I'm unable to boot into multi-user mode anymore. Additionally, in single user-mode with my bpool, whenever I execute the "zpool import it rpool", the panic occurs shortly after. My kdb backtrace log is attached to this url. <a href="https://ibb.co/v6d4Kr7K" target="_blank"><https://ibb.co/v6d4Kr7K></a>; I'm using FreeBSD 15.0-CURRENT main-n275975-5963423232e8. </pre> </blockquote> <pre>This looks like an assert; you may be able to boot again using either a RELEASE if your zpool hasn't been upgraded past that point, or a GENERIC-NODEBUG from CURRENT. This would at least get you working, but it won't fix the underlying cause. hope it helps, A+ Dave </pre> </blockquote> <pre cols="72">-- Seyed Pouria Mousavizadeh Tehrani Hoopad Cloud (AS214145) </pre> </div> </div></blockquote></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3vBuZPj=maUfToXLH_3JP2nRO3-MuNT%2BGikFpKea5d5%2BA>