From nobody Thu Jan 30 11:35:42 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YkH6958crz5m54d for ; Thu, 30 Jan 2025 11:36:17 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YkH670tQJz3lQV for ; Thu, 30 Jan 2025 11:36:14 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="QeMl/fsh"; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id DFC47240F14; Thu, 30 Jan 2025 12:36:12 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id F3B5124050D; Thu, 30 Jan 2025 12:36:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1738236970; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JSEs980FqFswRubeiFu9lWMtSuYmmaZIMPO2jH5lHFc=; b=QeMl/fsh/cQbQKtpXrvkP5pS2FVGOkeI2knDVZfl7M93W2VhTOeP7BhcFv45cZgkmFOoaE gvf9vcRViNkbj5fSO7Sbe5+5Y3FQxYiNJsgmOaLPi+Dm/FK1jy8vcjgowKnROlw6nMfX8t kQeq55LkydqKsANChjsYzG6lnCkXLu+vR5RkHdwmN8w3qda+VaPiFpbrfYCummVlwAencz nV/oeV+Ayl9m4cimaNthEhVU/KnJYU7CBYTpLAUSynr6RkI0surjnv5Adp2QHuxF8J9K1o +G12jdtHFlhXPSMQV6oxzCWGyVPGy8WxjodSA8HmzE/UQxKcDjdpKxzHfX5v7w== Received: from thor.sb211.local (dynamic-2a02-3100-24da-8d02-b536-28ce-4e02-f5af.310.pool.telefonica.de [IPv6:2a02:3100:24da:8d02:b536:28ce:4e02:f5af]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id B706A24001B; Thu, 30 Jan 2025 12:36:10 +0100 (CET) Date: Thu, 30 Jan 2025 12:35:42 +0100 From: A FreeBSD User To: David Wolfskill Cc: freebsd-current@freebsd.org Subject: Re: ZFS: Rescue FAULTED Pool Message-ID: <20250130123354.2d767c7c@thor.sb211.local> In-Reply-To: References: <20250129112701.0c4a3236@freyja> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/x9E+Jfrzy=ApROEyGk+XtpV"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 100f5f X-Rspamd-UID: 6e4461 X-Spamd-Result: default: False [-6.70 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_SENDERSCORE_REPUT_9(-1.00)[85.220.129.31:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Spamd-Bar: ------ X-Rspamd-Queue-Id: 4YkH670tQJz3lQV --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 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--