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.
-----Original Message-----
From: Grant Edwards <grant.b.edwards@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 <confabulate@kintzios.com> wrote:
On Tuesday, 8 November 2022 03:31:07 GMT Grant Edwards wrote:Thanks. I guess I should have been more specific in my question.
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.>
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.
LMP
about 20 years old, or one that's used up all its spare sectors...-----Original Message-----
From: Grant Edwards <grant.b.edwards@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 <confabulate@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
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...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.
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,
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 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.
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?
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.
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 ...
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.
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 ...
On Wednesday, 9 November 2022 16:53:13 GMT Laurence Perkins wrote:
Badblocks doesn't ask to write anything at the end of the run. You
tell it whether you want a read test, a write-read test or a
read-write-read-replace test at the beginning.
Not to labour the point, but 'e2fsck -v -c' runs a read test and at
the end it informs me "... Updating bad block inode", even if it
came across no read errors (0/0/0) and consequently does not prompt
for a fs repair.
On 2022-11-12, Michael <confabulate@kintzios.com> wrote:
On Wednesday, 9 November 2022 16:53:13 GMT Laurence Perkins wrote:
Badblocks doesn't ask to write anything at the end of the run. You
tell it whether you want a read test, a write-read test or a
read-write-read-replace test at the beginning.
Not to labour the point, but 'e2fsck -v -c' runs a read test and at
the end it informs me "... Updating bad block inode", even if it
came across no read errors (0/0/0) and consequently does not prompt
for a fs repair.
That's _e2fsck_ thats doing the writing at the end, not badblocks. The statement was that _badblocks_ doesn't ask to write anything at the
end of the run.
Have your questions been answered satisfactorily by Lawrence's contribution?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 303 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 78:09:02 |
| Calls: | 6,805 |
| Calls today: | 1 |
| Files: | 12,328 |
| Messages: | 5,400,433 |