Does ext4 update the bad blocks inode when a read/write failure is detected in a
mounted filesystem? If not, is safe a daily/weekly "fsck.ext4 -n -c device" on a
mounted filesystem? Would be safe even on a raid volume?
Unfortunately, still no Bad Block Relocation Target for lvm2 so I'm interested
in similar fs features.
Thanks,
Francesco
On Sep 18, 2009 20:26 +0000, Francesco Pretto wrote:
> Does ext4 update the bad blocks inode when a read/write failure is
> detected in a mounted filesystem? If not, is safe a daily/weekly
> "fsck.ext4 -n -c device" on a mounted filesystem? Would be safe even
> on a raid volume?
This isn't even safe on an UNMOUNTED filesystem, since "badblocks"
by default does destructive testing of the block device. 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.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
2009/9/18 Andreas Dilger <[email protected]>:
>
> This isn't even safe on an UNMOUNTED filesystem, since "badblocks"
> by default does destructive testing of the block device.
With destructive testing, I think you mean here a read/write test,
since a read only test isn't supposed to be destructive (usually).
According to badblocks(8), option -n, "By default only a
non-destructive read-only test is done". Moreover, according to
fsck.ext4(8), option -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" and later "If this option is specified
twice, then the bad block scan will be done using a non-destructive
read-write test". So I think the *potentially* unsafe command you
meant was "fsck.ext4 -n -c -c device".
Assuming that the manual is correct, and "fsck.ext4 -n -c device" does
really perform a read-only test opening the fs just to update the bad
blocks inode, my question still persists: is safe to launch it weekly
on a mounted filesystem? The wording of the manual seems to tell "yes,
it's supposed to be safe but don't do it because of <unexplained
reason>" :-)
> 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. 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.
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.
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
Francesco Pretto wrote:
> 2009/9/18 Andreas Dilger <[email protected]>:
...
>> 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