lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4AB4E3AA.2040103@redhat.com>
Date:	Sat, 19 Sep 2009 08:59:06 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Francesco Pretto <ceztkoml@...il.com>
CC:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: Does ext4 perform online update of the bad blocks inode?

Francesco Pretto wrote:
> 2009/9/18 Andreas Dilger <adilger@....com>:

...

>> Since most
>> disks will internally relocate bad blocks on writes, it is very
>> unlikely that "badblocks" will ever find a problem on a new disk.
>>
> 
> I'd like to believe you but please read the "smartctl --all" output
> (attached) for a Toshiba 120GB notebook drive I recently replaced, or
> just observe this excerpt:
> 
>   5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail
> Always       -       2
> 196 Reallocated_Event_Count 0x0032   100   100   000    Old_age
> Always       -       2
> ....
> Num  Test_Description    Status                  Remaining
> LifeTime(hours)  LBA_of_first_error
> # 1  Extended offline    Completed: read failure       00%      6366
>       57398211
> # 2  Extended offline    Completed: read failure       00%      6350
>       57398211
> 
> So, just 2 sectors reallocated but still read failures that are
> visible on the linux block device layer.

The disk won't reallocate on a read, only on a write.  So this is quite 
possible.

> I can guarantee this: I
> extensively repeated read tests on the disk, no way I could force the
> drive to relocate more failing sectors using its own SMART mechanism.
> So, what I mean is that hw bad blocks relocate features could not work
> as expected even on modern drives. Because of bugged implementation?
> Don't know.

No, it's expected.  Blocks can only be reallocated on a write (on a 
read, if it fails, what do you put into the new block?  You don't know 
what was there before so no idea what goes in the new block).

If the unreadable block is not in use on the fileystem, it's ok, because 
eventually when the fs writes to it the drive should reallocate.

If the unreadable block -is- in use, you're a little stuck; hopefully 
the fs gives you enough info about which block it is, and you could do a 
judicious "dd" of /dev/zero into it to force a reallocation, followed by 
a fsck I guess.

> You didn't answer my main question: does ext4 do something in case of
> a read/write failure that is detected in the block device layer?
> Exotic filesystems like NTFS (when running Windows, sure) seems to
> update its bad blocks list online, so it doesn't seems a bad think for
> notebook/desktop users.

Certainly not in kernelspace (well, it will return an EIO error to you, 
and possibly abort the filesystem, but that's all).

I've always felt like the badblocks list is a decades-old relic of the 
floppy days, to be honest.

If you have a sector you can't write to, you're done - the drive would 
have reallocated if it could, so get what you can off the drive and 
recycle it.

If you have a sector you can't read, it should be reallocated on the 
next write.

In neither case is a bad blocks list useful, IMHO.

-Eric

> The same problem is open for DM users: since evms is deprecated,
> there's no more a BBR target. So, for example, your buggy hard drive
> doesn't intercept the first and the only failing sector? The error
> arrives in the block device layer and the failing drive is
> deactived/removed from the RAID volume. Not good for me to throw away
> a disk for just one failing sector. This is matter for another mailing
> list, so please ignore.
> 
> Regards,
> Francesco

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ