On Tuesday, 8 November 2022 18:24:41 GMT Wols Lists wrote:
> MODERN DRIVES SHOULD NEVER HAVE AN OS-LEVEL BADBLOCKS LIST. If they do,
> something is seriously wrong, because the drive should be hiding it from
> the OS.
If you run badblocks or e2fsck you'll find the application asks to write data
>
>-Original Message-
>From: Michael
>Sent: Wednesday, November 9, 2022 12:47 AM
>To: gentoo-user@lists.gentoo.org
>Subject: Re: [gentoo-user] e2fsck -c when bad blocks are in existing file?
>
>On Tuesday, 8 November 2022 18:24:41 GMT Wols Lists wrote:
>
>> MODERN DRIVES SHOULD NEVER HAV
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 alrea
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. Reme
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 explici
Ok, so I decided to just go and test it myself.
I created a 2MiB file and formatted it as ext4 and mounted it.
I created a single, 100KiB file with a test pattern in this filesystem, and
then unmounted it.
I found the file in the raw storage with a hex editor, and computed a block
offset in th
6 matches
Mail list logo
