Date: Sat, 26 Feb 2022 17:13:39 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: Larry Rosenman <ler@lerctr.org> Cc: Rob Wing <rob.fx907@gmail.com>, Alexander Motin <mav@freebsd.org>, Freebsd current <freebsd-current@freebsd.org> Subject: Re: ZFS PANIC: HELP. Message-ID: <20220226171339.Horde.l4P5gYzg-XT3ZRAFvL4KBNq@webmail.leidinger.net> In-Reply-To: <d1db05269410cb5d8b0ba00b264d26e9@lerctr.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <a5f379a6-c2bd-f1e9-a281-bb657f3ccb75@FreeBSD.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <e9b95fed-9a3c-623c-c046-f0a7fd609eb6@FreeBSD.org> <CAF3%2Bn_fYSHLxYGp0jUbFg8%2BPFkEJAp7QMCX2BWMk4ePrn0=1yA@mail.gmail.com> <a414d6f4ad21af3044444b22acbe42bd@lerctr.org> <CAF3%2Bn_cevarxBYMJ5%2BGeTex6C%2Be-A79TbpDL-Pd7jsWPKfu=SA@mail.gmail.com> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <c2fb568ba91c61974cb439f6bda1aec3@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <d1db05269410cb5d8b0ba00b264d26e9@lerctr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed. --=_6wtqejNbDh9PhdsKDTzVZom Content-Type: multipart/alternative; boundary="=_IsRE-cZPUR6cZuTgtb5REjG" This message is in MIME format. --=_IsRE-cZPUR6cZuTgtb5REjG Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Description: Textnachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Larry Rosenman <ler@lerctr.org> (from Fri, 25 Feb 2022=20=20 20:03:51=20-0600): > On 02/25/2022 2:11 am, Alexander Leidinger wrote: > >> Quoting Larry Rosenman <ler@lerctr.org> (from Thu, 24 Feb 2022=20=20 >>=2020:19:45 -0600): >> >>> I tried a scrub -- it panic'd on a fatal double fault.=C2=A0 >>> >>> Suggestions? >> >> The safest / cleanest (but not fastest) is data export and=20=20 >>=20pool re-creation. If you export dataset by dataset (instead of=20=20 >>=20recursively all), you can even see which dataset is causing the=20=20 >>=20issue. In case this per dataset export narrows down the issue and=20= =20 >>=20it is a dataset you don't care about (as in: 1) no issue to=20=20 >>=20recreate from scratch or 2) there is a backup available) you could=20= =20 >>=20delete this (or each such) dataset and re-create it in-place (=3D not= =20=20 >>=20re-creating the entire pool). >> >> Bye, >> Alexander. >> http://www.Leidinger.net Alexander@Leidinger.net: PGP=20=20 >>=200x8F31830F9F2772BF >> http://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8= F31830F9F2772BF > > I'm running this script: > #!/bin/sh > for i in $(zfs list -H | awk '{print $1}') > do > =C2=A0 FS=3D$1 > =C2=A0 FN=3D$(echo ${FS} | sed -e s@/@_@g) > =C2=A0 sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh=20=20 >=20ler@freenas.lerctr.org cat - \> $FN > done > > =C2=A0 > > How will I know a "Problem" dataset? You told a scrub is panicing the system. A scrub only touches occupied=20= =20 blocks.=20As such a problem-dataset should panic your system. If it=20=20 doesn't=20panic at all, the problem may be within a snapshot which=20=20 contains=20data which is deleted in later versions of the dataset. Bye, Alexander. --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_IsRE-cZPUR6cZuTgtb5REjG Content-Type: text/html; charset=utf-8 Content-Description: HTML-Nachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">; <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"> <title></title> </head> <body style=3D"font-family:Arial;font-size:14px"> <p>Quoting Larry Rosenman <<a href=3D"mailto:ler@lerctr.org">ler@lerctr.= org</a>> (from Fri, 25 Feb 2022 20:03:51 -0600):</p> <blockquote style=3D"border-left:2px solid blue;margin-left:2px;padding-lef= t:12px;" type=3D"cite"> <p id=3D"reply-intro">On 02/25/2022 2:11 am, Alexander Leidinger wrote:</p> <blockquote style=3D"padding: 0 0.4em; border-left: #1010ff 2px solid; marg= in: 0" type=3D"cite"> <div id=3D"replybody1"> <div style=3D"font-family: Arial; font-size: 14px;"> <p>Quoting Larry Rosenman <<a href=3D"mailto:ler@lerctr.org" rel=3D"nore= ferrer">ler@lerctr.org</a>> (from Thu, 24 Feb 2022 20:19:45 -0600):</p> <blockquote style=3D"border-left: 2px solid blue; margin-left: 2px; padding= -left: 12px;"> <p>I tried a scrub -- it panic'd on a fatal double fault. </p> <p>Suggestions?</p> </blockquote> <p>The safest / cleanest (but not fastest) is data export and pool re-creat= ion. If you export dataset by dataset (instead of recursively all), you can= even see which dataset is causing the issue. In case this per dataset expo= rt narrows down the issue and it is a dataset you don't care about (as in: = 1) no issue to recreate from scratch or 2) there is a backup available) you= could delete this (or each such) dataset and re-create it in-place (=3D no= t re-creating the entire pool).<br> <br> Bye,<br> Alexander.</p> <div><a href=3D"http://www.Leidinger.net" rel=3D"noopener noreferrer" targe= t=3D"_blank">http://www.Leidinger.net</a>; <a href=3D"mailto:Alexander@Leidi= nger.net" rel=3D"noreferrer">Alexander@Leidinger.net</a>: PGP 0x8F31830F9F2= 772BF<br> <a href=3D"http://www.FreeBSD.org" rel=3D"noopener noreferrer" target=3D"_b= lank">http://www.FreeBSD.org</a> <a href=3D"mailto:netchild@Fr= eeBSD.org" rel=3D"noreferrer">netchild@FreeBSD.org</a> : PGP 0x8F3183= 0F9F2772BF</div> </div> </div> </blockquote> <p>I'm running this script:<br> #!/bin/sh<br> for i in $(zfs list -H | awk '{print $1}')<br> do<br> FS=3D$1<br> FN=3D$(echo ${FS} | sed -e s@/@_@g)<br> sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh ler@freenas.lerctr.org= cat - \> $FN<br> done</p> <p> </p> <p>How will I know a "Problem" dataset?</p> </blockquote> <p>You told a scrub is panicing the system. A scrub only touches occupied b= locks. As such a problem-dataset should panic your system. If it doesn't pa= nic at all, the problem may be within a snapshot which contains data which = is deleted in later versions of the dataset.<br> <br> Bye,<br> Alexander.<br></p> <div><a href=3D"http://www.Leidinger.net" target=3D"_blank">http://www.Leid= inger.net</a> <a href=3D"mailto:Alexander@Leidinger.net">Alexander@Leidinge= r.net</a>: PGP 0x8F31830F9F2772BF<br> <a href=3D"http://www.FreeBSD.org" target=3D"_blank">http://www.FreeBSD.org= </a> <a href=3D"mailto:netchild@FreeBSD.org">netchild@FreeBSD.= org</a> : PGP 0x8F31830F9F2772BF</div> </body> </html> --=_IsRE-cZPUR6cZuTgtb5REjG-- --=_6wtqejNbDh9PhdsKDTzVZom Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIaUbIACgkQEg2wmwP4 2IbSuA//T121fzZQ8X/pGxkBSDRqBU95Nq4ZSSxw/9jMCLLN97smAYD/YTeer4W3 uzk1nEIfP3Mvq5fVoBlE3S2K/lWPP9sE4n2MmSzQJmlZO/P9VkW+FhFn2aEAjDlm SzRjnOd2qgqdGVAuJKqAfcVudJaqKqC/W/8+4taE+/o2EhbwY3j0fr+kSvp6hjRr WnKMLpMaVOnSOEZ3BOdhilXssDZ8/hEuCrQV8mpAEHDeJz/taTI+Vqi+0nxOQ+zl P3gfgmBQZwiKtzT3lemS8fNeS7ktSsSGaXzPAc9uAfFJacQuIR+/jzE/FMwQOa9H eZxc/QwkgHZMhY5uz61zPTvU2kM/184wqJ6wsQlK13rw80SjaY+3voaDD7+L9oWz 7THTjMlRzgZEzV90bdhTbFzMa/UmwbAeVsZJmM70p5mAOUJn1fRDqehzEZ4FqFQk nLqgD+B8rjf5kVJYl/0/24JOvfx4TZxUgAgTI2mWRetVxT+zvk6IjyUJnqSCnXri 7mUp/6Knu98AJU2gQUAygQcIFlpkD7fczKCicWEGIDFYQm4Erecks5b+QwMQFLJh bkRFFCnsy/Lw6oX8T59l7DQ7oxl2Av1/rZb43G7JjB+AZFvSgge+3yM/aYHvbxrz Xzmo6tsNgjgwJPUzWVvRSZVxOR3dUp6i2cmRGbz+/zfp2QHZksI= =wrbT -----END PGP SIGNATURE----- --=_6wtqejNbDh9PhdsKDTzVZom--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220226171339.Horde.l4P5gYzg-XT3ZRAFvL4KBNq>