Date: Wed, 29 Jan 2025 19:24:40 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 284437] zdb -y somepool fails Message-ID: <bug-284437-227-saWAedLch9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-284437-227@https.bugs.freebsd.org/bugzilla/> References: <bug-284437-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D284437 peter@wemm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter@wemm.org --- Comment #1 from peter@wemm.org --- There has been a lot of confusion about this message. What we know: 1) The command can detect corruption, but 2) the command has internal limits to avoid excessive memory consumption.=20 These limits probably seemed reasonable at the time but they are easily rea= ched by a lot of people on perfectly healthy pools. Presumably the limits need t= o be adjusted. 3) The #2 false positive is scaring the heck out of people for no good reas= on. If you read the github bug https://github.com/openzfs/zfs/issues/15030 you'= ll see that people have been recovering pools. On linux they set zil_replay_disable (via procfs) to mount the damaged pool and then and zfs_recover (via procfs) and run a scrub. We have equivalent sysctls. YMM= V of course. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-284437-227-saWAedLch9>