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 4AA5E158020 for ; Thu, 10 Nov 2022 00:19:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6214E08F6; Thu, 10 Nov 2022 00:18:56 +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 6B4D0E08C8 for ; Thu, 10 Nov 2022 00:18:56 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1osvHS-0008mH-V1 for gentoo-user@lists.gentoo.org; Thu, 10 Nov 2022 01:18:54 +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: Thu, 10 Nov 2022 00:18:46 -0000 (UTC) Message-ID: References: <3193783.oiGErgHkdL@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: 10af4c66-cb7d-4c55-b5d1-e48f31b20053 X-Archives-Hash: ff2b10c1340cdc460a45b5b5a79ab9c4 On 2022-11-09, Wol wrote: > On 09/11/2022 23:31, Grant Edwards wrote: >>> If I recall correctly, it will add any unreadable blocks to its >>> internal list of bad sectors, which it will then refuse to allocate >>> in the future. > > I doubt you recall correctly. The e2fsck man page states explicitly that a -c read failure will cause the block to be added to the bad block inode. You're claiming that is not what happens? > You should ONLY EVER conclude a block is bad if you can't write to > it. Remember what I said - if I read my 8TB drive from end-to-end > twice, then I should *expect* a read error ... OK... >> I'm asking what happens to the file containing the bad block. Perphaps >> nothing. The man page says the block is added to the "bad block >> inode". If that block was already allocated, is the bad block is now >> allocated to two different inodes? > > If a read fails, you SHOULD NOT do anything. Thanks, but I'm not asking what I should do. I'm not asking what the filesystem should do. I'm not asking what disk-drive controller firmware should do or does do with failed/spare blocks. I'm asking what e2fsck -c does when the bad block is already allocated to an inode. Specifically: Is the bad block removed from the inode to which it was allocated? Is the bad block left allocated to the previous inode as well as being added to the bad block inode? We've gotten lots of answers to lots of other questions, but after re-reading the thread a few times, I still haven't seen an answer to the question I asked. > If a write fails, you move the block and mark the failed block as > bad. But seeing as you've moved the block, the bad block is no > longer allocated to any file ... Are you stating e2fsck -c will removed bad block from the inode to which it was allocated before the scan? Is it replaced with a different block? Or just left as an empty "hole" that can't be read from or written to? The e2fsck man page does not state that the bad block is removed from the old inode, only that that bad block is added to the bad block inode. If a block is allocated to an inode, I would call that "allocated to a file". It's not a file that has a visible name that shows up in a directory, but it's still a file. -- Grant