Date: Tue, 31 Oct 2023 15:27:33 +0100 From: Alexander Leidinger <alexleidingerde@gmail.com> To: John F Carr <jfc@mit.edu> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, mm@freebsd.org Subject: Re: ZFS txg rollback: expected timeframe? Message-ID: <CAJg7qzEnQFUS4v=zYjch3KTySxuErnwC2E5zYTwMB5UkfoTV6g@mail.gmail.com> In-Reply-To: <18B0B6B6-9237-42D0-9FB2-D55CE72E1CCA@mit.edu> References: <CAJg7qzHONfMeLUm20OE6Jo5uFLt9bY5VVhbY8z%2BoEVcHYwyoXw@mail.gmail.com> <18B0B6B6-9237-42D0-9FB2-D55CE72E1CCA@mit.edu>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Tue, Oct 31, 2023 at 1:15 PM John F Carr <jfc@mit.edu> wrote: > > > > On Oct 31, 2023, at 06:16, Alexander Leidinger < > alexleidingerde@gmail.com> wrote: > > > > Issue: a overheating CPU may have corrupted a zpool (4 * 4TB in raidz2 > setup) in a way that a normal import of the pool panics the machine with > "VERIFY3(l->blk_birth == r->blk_birth) failed (101867360 == 101867222)". > > > > I disabled that assertion because it gives a false alarm with some > combinaion > of deduplication, cloning, and snapshotting on one of my systems. > > See > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261538 > https://github.com/openzfs/zfs/issues/11480 I don't have deduplication on this pool. There are clones, and snapshots, and there could be recent ones if poudriere does some. Is it still a false alarm in this case? If yes, you say a kernel with this patch applied should let me import the pool without rollback? The github issue is from 2022, I have my doubts that this is the same issue we see. I rather expect some issues around the copy_file_range(2) related code for ZFS which was re-enabled 20 days ago (maybe it is valid to remove this assert, or maybe the block cloning part needs some tweak). CC Martin for the block cloning part. Bye, Alexander. [-- Attachment #2 --] <div dir="ltr"><div dir="ltr">On Tue, Oct 31, 2023 at 1:15 PM John F Carr <<a href="mailto:jfc@mit.edu">jfc@mit.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> > On Oct 31, 2023, at 06:16, Alexander Leidinger <<a href="mailto:alexleidingerde@gmail.com" target="_blank">alexleidingerde@gmail.com</a>> wrote:<br> > <br> > Issue: a overheating CPU may have corrupted a zpool (4 * 4TB in raidz2 setup) in a way that a normal import of the pool panics the machine with "VERIFY3(l->blk_birth == r->blk_birth) failed (101867360 == 101867222)".<br> > <br> <br> I disabled that assertion because it gives a false alarm with some combinaion<br> of deduplication, cloning, and snapshotting on one of my systems.<br> <br> See<br> <br> <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261538" rel="noreferrer" target="_blank">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261538</a><br>; <a href="https://github.com/openzfs/zfs/issues/11480" rel="noreferrer" target="_blank">https://github.com/openzfs/zfs/issues/11480</a></blockquote><div><br></div><div>I don't have deduplication on this pool. There are clones, and snapshots, and there could be recent ones if poudriere does some. Is it still a false alarm in this case? If yes, you say a kernel with this patch applied should let me import the pool without rollback?</div><div><br></div><div>The github issue is from 2022, I have my doubts that this is the same issue we see. I rather expect some issues around the copy_file_range(2) related code for ZFS which was re-enabled 20 days ago (maybe it is valid to remove this assert, or maybe the block cloning part needs some tweak). CC Martin for the block cloning part.</div><div><br></div><div>Bye,</div><div>Alexander.</div></div></div>help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJg7qzEnQFUS4v=zYjch3KTySxuErnwC2E5zYTwMB5UkfoTV6g>