Does ext4 perform online update of the bad blocks inode?

Does ext4 perform online update of the bad blocks inode?

[Francesco Pretto]

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

Re: Does ext4 perform online update of the bad blocks inode?

[Andreas Dilger]

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.

Re: Does ext4 perform online update of the bad blocks inode?

[Francesco Pretto]

[-- Attachment #1: Type: text/plain, Size: 3088 bytes --]

2009/9/18 Andreas Dilger <adilger@sun.com>:
>
> 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

[-- Attachment #2: smartctl-all --]
[-- Type: application/octet-stream, Size: 11056 bytes --]

smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 2.5" HDD series (80 GB and above)
Device Model:     TOSHIBA MK1234GSX
Serial Number:    967X0076T
Firmware Version: AH001A
User Capacity:    120,034,123,776 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sat Sep 19 12:33:40 2009 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      ( 112)	The previous self-test completed having
					the read element of the test failed.
Total time to complete Offline 
data collection: 		 ( 435) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  86) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       1722
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       3215
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       2
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   084   084   000    Old_age   Always       -       6694
 10 Spin_Retry_Count        0x0033   164   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       3198
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       195
193 Load_Cycle_Count        0x0032   071   071   000    Old_age   Always       -       295410
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       26 (Lifetime Min/Max 10/60)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       2
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x0032   200   253   000    Old_age   Always       -       3
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       69
222 Loaded_Hours            0x0032   087   087   000    Old_age   Always       -       5349
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       632
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 25 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 25 occurred at disk power-on lifetime: 6693 hours (278 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 02 c3 d3 6b 43

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 58 00 6d d3 6b 40 00      01:38:36.750  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      01:38:36.750  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      01:38:36.749  IDENTIFY DEVICE
  ef 03 45 00 00 00 a0 00      01:38:36.749  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      01:38:36.749  READ NATIVE MAX ADDRESS EXT

Error 24 occurred at disk power-on lifetime: 6693 hours (278 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 0a c3 d3 6b 43

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 58 08 6d d3 6b 40 00      01:38:29.995  READ FPDMA QUEUED
  60 66 00 5f d4 6b 40 00      01:38:29.994  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      01:38:29.994  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      01:38:29.993  IDENTIFY DEVICE
  ef 03 45 00 00 00 a0 00      01:38:29.993  SET FEATURES [Set transfer mode]

Error 23 occurred at disk power-on lifetime: 6693 hours (278 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 02 c3 d3 6b 43

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 66 08 5f d4 6b 40 00      01:38:23.251  READ FPDMA QUEUED
  60 58 00 6d d3 6b 40 00      01:38:23.250  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      01:38:23.250  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      01:38:23.249  IDENTIFY DEVICE
  ef 03 45 00 00 00 a0 00      01:38:23.249  SET FEATURES [Set transfer mode]

Error 22 occurred at disk power-on lifetime: 6693 hours (278 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 12 c3 d3 6b 43

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 58 10 6d d3 6b 40 00      01:38:09.971  READ FPDMA QUEUED
  60 66 08 5f d4 6b 40 00      01:38:09.971  READ FPDMA QUEUED
  60 9a 00 c5 d3 6b 40 00      01:38:09.971  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      01:38:09.970  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      01:38:09.969  IDENTIFY DEVICE

Error 21 occurred at disk power-on lifetime: 6693 hours (278 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 02 c3 d3 6b 43

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 9a 10 c5 d3 6b 40 00      01:38:03.226  READ FPDMA QUEUED
  60 66 08 5f d4 6b 40 00      01:38:03.226  READ FPDMA QUEUED
  60 58 00 6d d3 6b 40 00      01:38:03.226  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      01:38:03.226  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00      01:38:03.225  IDENTIFY DEVICE

SMART Self-test log structure revision number 1
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
# 3  Extended offline    Completed without error       00%      4532         -
# 4  Extended offline    Aborted by host               90%      4531         -
# 5  Extended offline    Interrupted (host reset)      70%      4530         -
# 6  Extended offline    Completed without error       00%      3655         -
# 7  Extended offline    Aborted by host               90%      3654         -
# 8  Extended offline    Completed without error       00%      3567         -
# 9  Short offline       Completed without error       00%      3565         -
#10  Short offline       Completed without error       00%      1837         -
#11  Short offline       Completed without error       00%      1785         -
#12  Short offline       Completed without error       00%      1780         -
#13  Short offline       Completed without error       00%      1681         -
#14  Short offline       Completed without error       00%      1663         -
#15  Short offline       Completed without error       00%      1661         -
#16  Short offline       Completed without error       00%      1646         -
#17  Short offline       Completed without error       00%      1608         -
#18  Short offline       Completed without error       00%      1601         -
#19  Short offline       Completed without error       00%      1584         -
#20  Short offline       Completed without error       00%      1564         -
#21  Short offline       Interrupted (host reset)      40%      1421         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Re: Does ext4 perform online update of the bad blocks inode?

[Eric Sandeen]

Francesco Pretto wrote:
> 2009/9/18 Andreas Dilger <adilger@sun.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