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 9D8C1158020 for ; Wed, 9 Nov 2022 23:31:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A748CE086D; Wed, 9 Nov 2022 23:31:43 +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 6D42AE0863 for ; Wed, 9 Nov 2022 23:31:43 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1osuXj-0001Qc-Qx for gentoo-user@lists.gentoo.org; Thu, 10 Nov 2022 00:31:39 +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: Wed, 9 Nov 2022 23:31:33 -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: 3ecce82d-0752-4866-ae92-30a0fc90a213 X-Archives-Hash: 2fc7b0aec23defd3fb01290ab4a3ac06 On 2022-11-08, Laurence Perkins wrote: >>> >>>> What happens when the bad block is _already_allocated_ to a file? >> >>> [...] >> >>Thanks. I guess I should have been more specific in my question. >> >>What does e2fsck -c do to the filesystem structure when it discovers >>a bad block that is already allocated to an existing inode? >> >>Is the inode's chain of block groups left as is -- still containing >>the bad block that (according to the man page) "has been added to >>the bad block inode"? Presumably not, since a block can't be >>allocated to two different inodes. >> >>Is the "broken" file split into two chunks (before/after the bad >>block) and moved to the lost-and-found? >> >>Is the man page's description only correct when the bad block is >>currently unallocated? > > 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'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? > I don't believe it will attempt to move the file to elsewhere until > it is written since: > > A) what would you then put in that block? You don't know the contents. You wouldn't put anything in that block. One solution that comes to mind would be to truncate the file immediately before the bad block (we'll call that truncated file the "head"). Then you allocate a new inode to which you assign all of the blocks after the bad block (we'll call that the "tail"). The bad block is then moved to the "bad blocks inode" and the head/tail files are moved into the lost+found. > B) Moving the file around would make attempts to recover the data > from that bad sector significantly more difficult. Yes, probably. Any manipulation of a filesystem (like adding the block to the bad block inode) on a failing disk seems like a bad idea. -- Grant