From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C51CC158020 for ; Sun, 13 Nov 2022 03:54:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC040E0920; Sun, 13 Nov 2022 03:54:52 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8F8D2E08C8 for ; Sun, 13 Nov 2022 03:54:52 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ou455-0000DU-6T for gentoo-user@lists.gentoo.org; Sun, 13 Nov 2022 04:54:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? Date: Sun, 13 Nov 2022 03:54:43 -0000 (UTC) Message-ID: References: <4228101.ejJDZkT8p0@lenovo.localdomain> <3134643.5fSG56mABF@lenovo.localdomain> User-Agent: slrn/1.0.3 (Linux) 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 X-Archives-Salt: cf5ae041-ef02-4bc7-ab74-fcd2c190ee1e X-Archives-Hash: ca4ce1fb423b7509e0755912a89fbddd On 2022-11-12, Michael wrote: > Have your questions been answered satisfactorily by Lawrence's contribution? Yes, Lawrence's experiment answered the my question: e2fsck adds the bad block to the "bad block" inode and leaves it also allocated to the existing file. Presumably if you don't allow it to clone the block, reading that file will return an error when it gets to the bad block. Once you delete that file, the bad block will never get reallocated by the filesystem since it still belongs to the bad block inode. The failing SSD that prompted the question has now been replaced and a fresh Gentoo system installed on the new drive. I never did figure out which files contained the bad blocks (there were 37 bad blocks, IIRC). They apparently didn't belong to any of the files I copied over to the replacement drive. The old drive was a Samsung 850 EVO SATA drive, and the new one is a Samsung 980 PRO M.2 drive. The new one is noticably faster than the old one (which in turn was way faster than the spinning platter drive it had replaced). -- Grant