On Tue, 08 Nov 2022 12:55:51 -0500, Laurence Perkins wrote: > > > > >-----Original Message----- > >From: Grant Edwards <grant.b.edwa...@gmail.com> > >Sent: Tuesday, November 8, 2022 6:28 AM > >To: gentoo-user@lists.gentoo.org > >Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? > > > >On 2022-11-08, Michael <confabul...@kintzios.com> wrote: > >> On Tuesday, 8 November 2022 03:31:07 GMT Grant Edwards wrote: > >>> I've got an SSD that's failing, and I'd like to know what files > >>> contain bad blocks so that I don't attempt to copy them to the > >>> replacement disk. > >>> > >>> According to e2fsck(8): > >>> > >>> -c This option causes e2fsck to use badblocks(8) program to > >>> do > >>> a read-only scan of the device in order to find any bad blocks. If > >>> any bad blocks are found, they are added to the bad block inode to > >>> prevent them from being allocated to a file or directory. If this > >>> option is specified twice, then the bad block scan will be done > >>> using a non-destructive read-write test. > >>> > >>> What happens when the bad block is _already_allocated_ to a file? > > > >> Previously allocated to a file and now re-allocated or not, my > >> understanding is with spinning disks the data in a bad block stays > >> there unless you've dd'ed some zeros over it. Even then read or write > >> operations could fail if the block is too far gone.[1] Some data > >> recovery applications will try to read data off a bad block in > >> different patterns to retrieve what's there. Once the bad block is > >> categorized as such it won't be used by the filesystem to write new data > >> to it again. > > > >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? > > > >-- > >Grant > > 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 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. > B) Moving the file around would make attempts to recover the data from that > bad sector significantly more difficult. > > This is, however, very unlikely to come up on a modern disk since most of > them automatically remap failed sectors at the hardware level (also on write, > for the same reasons). So the only time it would matter is if you have a > disk that's more than about 20 years old, or one that's used up all its spare > sectors... > > Unless, of course, you're resurrecting the old trick of marking a section of > the disk as "bad" so the FS won't touch it, and then using it for raw data of > some kind... > > You can, of course, test it yourself to be certain with a loopback file and a > fake "badblocks" that just outputs your chosen list of bad sectors and then > see if any of the data moves. I'd say like a 2MB filesystem and write a file > full of 00DEADBEEF, then make a copy, blacklist some sectors, and hit it with > your favorite binary diff command and see what moved. This is probably > recommended since there could be differences between the behaviour of > different versions of e2fsck.
Maybe its time for spinwrite -- new version coming out soon, but it might save your bacon. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com