From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E413B1580E0 for ; Sat, 01 Feb 2025 00:14:39 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (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) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id CF6DC3431B3 for ; Sat, 01 Feb 2025 00:14:39 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id AA79D11047D; Sat, 01 Feb 2025 00:13:34 +0000 (UTC) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 744DF1103B6 for ; Sat, 01 Feb 2025 00:13:33 +0000 (UTC) Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2eec9b3a1bbso3485805a91.3 for ; Fri, 31 Jan 2025 16:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738368812; x=1738973612; darn=lists.gentoo.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Koz1LMAHNN/3lcJY1VS2l8w9/keQ9CU0v8m//YTTcfk=; b=j/JolTmrS1YuFrmNpCPXBcNXiW9G+3Hbss2rOoTYM3zD+AVJWjPDP9inrAECRASXhg Q2knzGqoBheOLRvXw7e8cbcX5dnGKREvl1w/jB0N7RaV3eN1F7USw5BTtxvBnMtPrJFW oYHWfbVbCq9lWvhLF66e8BmUsF1knGI+ZelRfJQB1pbCd3fg9a+dtlo7NSELN1HlScHv fD7ov9bXeWxawmzktjXLE6XmX42AXRXCrkdJoFQo4bx4OCLjH0KkZwDCXIeWdVIdSC5i qssNvaf24IpjfxkAFXZ90s9/0PcoxZ29p2+ohxqS5zHOuUam6cCli/QJ3njv35pGDcL+ A56w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738368812; x=1738973612; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Koz1LMAHNN/3lcJY1VS2l8w9/keQ9CU0v8m//YTTcfk=; b=MB3oHYBvcmWh1oE3rSfybLgl/7G2QLDdVY9NpfOAiWJb34OfPId+WTWNFebsOlibKV s23qavIO4f+fOTgXUlOUCxEJ/FakfK3sR+xITMhQP3qpHlizSoG+N96ff6MCnauaRjz5 EwNjfZsVwYmE09vfUobP6sjjo9kAXILCm/NnV9hESNTQJ7bUPnahooTkukt/Mk5ZRpkh gcsCXAHYmf4yWZtbjVwE+3zVfRBsUXEYa4JotGiDzOB7wkD6lGMVtBYhxOhczLo/zUeM AuXIbwNQI+xs5ryv8c72NXbgCUhd9kuMh3lbCEGf1EWU+TvIbNuyQEGtk0oIMUFz+HJ3 xzMQ== X-Gm-Message-State: AOJu0YwFKousnwu4RcbpjhjvCOnp2TJ/owJulczsXumjtCOmaI+674ts MhXuAOZynSuwPdnn6WuX7Hw02hLJqf08NQQvjw6TojinMRr1a9/v3u7NaqBlsiCFEspETbwQT7+ Ei322arl44E9Aw8dyL54YPAzHQLwyZ1b6 X-Gm-Gg: ASbGnctv684JV6MX7/iY2Vy1Bc7R0/0Nqaua9kr9jRJ8eh120N3uMwD2G6KG4PqmIco YNqpHgXuDGbVwvp+O1ITk+KHIwl6BJfSlwqQoWU5kh4F+cqUNlxdaBeDt45ZXsIly725gXyDvt2 g= X-Google-Smtp-Source: AGHT+IEMpCKa5dJB55mjAD+j5a0Fz48wyjRPvO0qmbhgyOPSZWXriu+vqrSc/QNhimvxisDEzRjHAdVaZZdtMmaLC6w= X-Received: by 2002:a17:90b:2742:b0:2ee:9a82:5a93 with SMTP id 98e67ed59e1d1-2f83abf3745mr20938096a91.14.1738368812492; Fri, 31 Jan 2025 16:13:32 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <3335789.aeNJFYEL58@rogueboard> In-Reply-To: <3335789.aeNJFYEL58@rogueboard> From: gevisz Date: Sat, 1 Feb 2025 02:13:24 +0200 X-Gm-Features: AWEUYZnWWYW39o-_MUItFqQYH10qRpF7fQi2lzDQ1-mQW__V1KhtxtBvPQ7aHm4 Message-ID: Subject: Re: [gentoo-user] Problem with detecting ZFS HDD To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 66bc27d8-d16a-42f3-ad50-314b6874b88a X-Archives-Hash: bd053700c7c2dcf1fd7b283dcdbbfeb3 =D0=BF=D1=82, 31 =D1=8F=D0=BD=D0=B2. 2025=E2=80=AF=D0=B3. =D0=B2 13:26, Mic= hael : > > On Thursday 30 January 2025 16:55:00 Greenwich Mean Time gevisz wrote: > [snip ...] > > > After setting up one of them as a ZFS mirror, I immediately > > got the problem that if I boot my system with additional HDD > > connected to my computer, one of these ZFS mirror disks > > is not detected and the corresponding zpool appears to be degraded. > > > > I have realized that it was my fault to use /dev/sdb and /dev/sdc > > notations when setting up the ZFS mirror because with more disks > > at the boot time these notations may change. > > > > I should have used /dev/disk/by-id/ata-WDC_WD5000* notations instead! > > With ZFS you should probably have used the unique device ID obtained by > running: > > lsblk -o name,wwn Currently, at least one of these ZFS disks does not report its wwn nor via your command above, neither to the /dev/disk/by-id/ directory. However, they both report itself to the /dev/disk/by-id/ directory as /dev/disk/by-id/ata-WDC_WD5000* That was the reason why I used the latter format when setting up my zpool. However, when I boot with external USB HDD or another additional SATA HDD, this ZFS HDD does not report himself to the directory /dev/disk/by-id/ at all (and to the lsblk command as well), and so ZFS does not find it. > My ZFS experience is cursory to know it if makes a material difference, b= ut > according to the Gentoo wiki page this is what OpenZFS prefers: > > https://wiki.gentoo.org/wiki/ZFS#Preparing_disk My system starts from a XFS partition on another HDD, so I did not "prepared" these HDDs at all, leaving everything to ZFS itself as it is recommended in the documentation. That is, I have not partitioned them and have not formated them with any file system. > > Unfortunately, I have not found the way to change these notations > > other than deleting the whole zpool and re-creating it anew with > > the notations /dev/disk/by-id/ata-WDC_WD5000*, which took quite > > a lot of time. > > > > Presumably, the problem with detecting my ZFS mirror HDDs > > should have disappeared after that because now the disks were > > referred to by their ids but unfortunately it was not the case. > > > > When I boot my computer with an additional external HDD > > attached to the computer via USB, one of my ZFS mirror HDDs > > is not detected by the system and the corresponding zpool again > > appears to be degraded until I restart my computer in the usual > > setup, that is, without any additional HDD attached to it. > > > > I have looked into my /dev/disk/by-id/ directory and found out > > that this happens because one of these ZFS mirror HDDs > > does not appear in this directory at all! > > When USB drives are plugged in, or the system boots with a USB drive alre= ady > plugged in, they may not be detected in the same order against other conn= ected > drives and their logical device name can change e.g. from /dev/sdb to /de= v/ > sdc. > > However, this will not stop a HDD from being detected. Its logical name = may > change, but the disk by-id and wwn will not. The problem is that after booting with an additional HDD, one of these ZFS HDDs does not report any of its disk id: nor wwn neighter in the form ata-WDC_WD5000*. > > The situation remained the same even after swapping the > > undetected 500GB WD HDD with the one. And now, this makes me think that the problem is indeed with the SATA port. > > So, I wonder if it is a fault of > > 1) refurbished WD HDDs > > Run smartctl tests to see what they detect. Any error reported indicates= a > hardware problem. I have run all possible disk checks after buying these HDD disks and everyt= hing was ok with them, except the fact that not all smart data was available to = me. For example, the number of hours these disks have been worked was unavailab= le. However, after some time, one of the disks reported bad sectors. So, I have swapped it for the spare one, deleted all information from it and was prepared to return it to the seller, but found out that after that operation all the bad sectors magically disappeared from the disk. I think that these bad sectors appeared after sudden outages that we experienced at the time during blackouts. After buying UPS, I swapped the disks back and now the "repared" in such a way HDD works without any bad sectors for quite a long time. > > 2) my almost 20 years old Ultra-Durable Gigabyte motherboard > > Try a different SATA port and cable from what you've been using so far to > connect the second hard drive. Either may be faulty. I now think that this is the most probable reason. Thank you for the suggestion. I will try this. > > 3) the Linux system itself. > > Highly unlikely, but booting with a liveUSB will soon confirm this. Thank you for this suggestion as well and for all your insites in general.