Date: Thu, 30 Jan 2025 12:35:42 +0100 From: A FreeBSD User <freebsd@walstatt-de.de> To: David Wolfskill <david@catwhisker.org> Cc: freebsd-current@freebsd.org Subject: Re: ZFS: Rescue FAULTED Pool Message-ID: <20250130123354.2d767c7c@thor.sb211.local> In-Reply-To: <Z5oU1dLX4eQaN8Yq@albert.catwhisker.org> References: <20250129112701.0c4a3236@freyja> <Z5oU1dLX4eQaN8Yq@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/x9E+Jfrzy=ApROEyGk+XtpV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 29 Jan 2025 03:45:25 -0800 David Wolfskill <david@catwhisker.org> schrieb: Hello, thanks for responding. > On Wed, Jan 29, 2025 at 11:27:01AM +0100, FreeBSD User wrote: > > Hello, > >=20 > > a ZFS pool (RAINDZ(1)) has been faulted. The pool is not importable > > anymore. neither with import -F/-f. > > Although this pool is on an experimental system (no backup available) > > it contains some data to reconstruct them would take a while, so I'd > > like to ask whether there is a way to try to "de-fault" such a pool. =20 >=20 > Well, 'zpool clear ...' "Clears device errors in a pool." (from "man > zpool". >=20 > It is, however, not magic -- it doesn't actually fix anything. For the record: I tried EVERY network/search available method useful for c= ommon "administrators", but hoped people are abe to manipulate deeper stuff via z= db ... >=20 > (I had an issue with a zpool which had a single SSD device as a ZIL; the > ZIL device failed after it had accepted some data to be written to the > pool, but before the data could be read and transferred to the spinning > disks. ZFS was quite unhappy about that. I was eventually able to copy > the data elsewhere, destroy the old zpool, recreate it *without* that > single point of failure, then copy the data back. And I learned to > never create a zpool with a *single* device as a separate ZIL.) Well, in this case I do not use dedicated ZIL drives. I also made several e= xperiences with "single" ZIL drive setups, but a dedicated ZIL is mostly useful in cases we= re you have graveyard full of inertia-suffering, mass-spinning HDDs - if I'm right the = concept of SSD based ZIL would be of no use/effect in that case. So I ommited tose. >=20 > > The pool is comprised from 7 drives as a RAIDZ1, one of the SSDs > > faulted but I pulled the wrong one, so the pool ran into suspended > > state. =20 >=20 > Can you put the drive you pulled back in? Every single SSD originally plugged in is now back in place, even the fault= ed one (which doesn't report any faults at the moment). Although the pool isn't "importable", zdb reports its existence, amongst zr= oot (which resides on a dedicated drive). >=20 > > The host is running the lates Xigmanas BETA, which is effectively > > FreeBSD 14.1-p2, just for the record. > >=20 > > I do not want to give up, since I hoped there might be a rude but > > effective way to restore the pool even under datalosses ... > >=20 > > Thanks in advance, > >=20 > > Oliver > > .... =20 >=20 > Good luck! >=20 > Peace, > david Well, this is a hard and painful lecture to learn, if there is no chance to= get back the pool. A warning (but this seems to be useless in the realm of professionals): I u= sed a bunch of cheap spotmarket SATA SSDs, a brand called "Intenso" common also here in Go= od old Germany. Some of those SSDs do have working LED when used with a Fujitsu SAS HBA con= troller - but those died very quickly from suffering some bus errors. Another bunch of those SS= Ds do not have working LED (not blinking on access), but lasted a bit longer. The problem = with those SSDs is: I can not find the failing device easily by accessing the failed drive by w= riting massive data via dd, if possible.=20 I also ordered alternative SSDs from a more expensive brand - but bad Karma= ... Oliver --=20 A FreeBSD user --Sig_/x9E+Jfrzy=ApROEyGk+XtpV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCZ5tkKQAKCRCxzvs8Oqok rw4JAP4lmC86YPOdB2uE6S/3kwNfKnZTqHBocfbsogaBPVvxMwEApkGuSYCXZh24 XlgNWo3K/WTYRYEmtmijWDewrxyIagE= =VLTO -----END PGP SIGNATURE----- --Sig_/x9E+Jfrzy=ApROEyGk+XtpV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250130123354.2d767c7c>