Badblocks on XFS

Essentially the same as for ext[23] as shown on the smartmontools homepage. Please follow this example:

smartctl reports bad sector

# smartctl -a /dev/sda
[...]
# 1  Extended offline    Completed: read failure       90%      5702         36922326

Query fdisk

Ask fdisk to tell you which partition is affected:

# fdisk -ul /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63       80324       40131   83  Linux
/dev/sda2           80325    20563199    10241437+  83  Linux
/dev/sda3        20563200    28965194     4200997+  82  Linux swap / Solaris
/dev/sda4        28965195   976768064   473901435    5  Extended
/dev/sda5        28965258    31069709     1052226   83  Linux
/dev/sda6        31069773   976768064   472849146   83  Linux

Thus /dev/sd6 is affected in this case and sector 36922326-31069773=5852553 within sda6 has problems.

Ask xfs_info kindly for block size

xfs_info /dev/sda6
meta-data=/dev/sda6              isize=256    agcount=16, agsize=7388267 blks
         =                       sectsz=512   attr=1
data     =                       bsize=4096   blocks=118212272, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

This tells you that this file system uses block sizes of 4k (bsize).

Using the formula from the smartmontools HOWTO we get block 731569 to look at.

Use xfs_db for finding affected file

Warning ahead: If the file system under consideration is very large, there might be another way by using xfs_bmap and manually traverse the file system. xfs_db might run out of memory.

Please note that the file system needs to be umounted or at least mounted read-only for this operation!

n0811:~# xfs_db -i /dev/sda6
xfs_db> blockget -b 731569 -n
setting block 0/731569 to free1
setting block 0/731569 to free2
xfs_db>

This process takes about 900 MByte of RAM and several minutes on a 420 GB file system which is about 30% full. It will create a full file system mapping in memory thus further tasks will run much faster.

In this case the defective LBA seems to be in this air, i.e. no file at the destination. Thus we can simply overwrite it with dd.

If there were a file, the output would look like this, but first we need to find a block corresponding to a file:

# xfs_bmap -l  /local/boinc/time_stats_log
/local/boinc/time_stats_log:
        0: [0..127]: 280..407 128 blocks
        1: [128..159]: 728..759 32 blocks
        2: [160..167]: 1016..1023 8 blocks
        3: [168..183]: 54120..54135 16 blocks
        4: [184..207]: 656..679 24 blocks
        5: [208..215]: 3451664..3451671 8 blocks
        6: [216..255]: 3451624..3451663 40 blocks
        7: [256..287]: 3451672..3451703 32 blocks

Now one has to be careful with blocks here. the man page of xfs_bmap goes into some detail here:

Let's choose file's sector 220 which is in extend 6 (zero based counting): 3451624 + ( 220 - 216 ) = 3451628

This number is using 512byte sectors, using the bsize of 4096 for this file system, this yields: int(3451628*512/4096) = 431453

Now we can check this with xfs_db:

xfs_db -r /dev/sda6
xfs_db> blockget -b 431453 -n
setting block 0/431453 to data
setting inode to 141 for block 0/431453
inode 141 block 431453 at offset 27
xfs_db> ncheck -i 141
        141 boinc/time_stats_log

Forcing the rewrite with dd

dd if=/dev/zero of=/dev/sda6 bs=4096 count=1 seek=731569

This forces the disk to rewrite the block under consideration (of course destroying the file if it happens to use this block) and the bad sector should go away. This can be tested with the selective test of smartmontools (this time with the disk LBA):

smartctl -t select,36922300-36922400 /dev/sda

-- CarstenAulbert - 28 Oct 2008