[LU-3420] OI scrubbing could not automatically engage after restoring a secondary MDT from a (file-level) backup

Related — Fri, 13 Sep 2013 03:43:39 +0000

When adapting sanity-scrub 4 to exercise not only MDT 0 but also the secondary MDTs, I found that, after restoring a secondary MDT from its file-level backup, looking up corresponding "remote" directory would return ENOENT on clients:

[root@linux tests]# ls /mnt/lustre/d0.sanity-scrub/d4/mdt1
ls: cannot access /mnt/lustre/d0.sanity-scrub/d4/mdt1: No such file or directory

"mdt1" was created by "lfs mkdir -i 1". And, OI scrubbing did not engage automatically:

[root@linux tests]# cat /proc/fs/lustre/osd-ldiskfs/lustre-MDT0001/oi_scrub
name: OI_scrub
magic: 0x4c5fd252
oi_files: 64
status: init
flags: inconsistent
param:
time_since_last_completed: N/A
time_since_latest_start: N/A
time_since_last_checkpoint: N/A
latest_start_position: N/A
last_checkpoint_position: N/A
first_failure_position: N/A
checked: 0
updated: 0
failed: 0
prior_updated: 0
noscrub: 0
igif: 0
success_count: 0
run_time: 0 seconds
average_speed: 0 objects/sec
real-time_speed: N/A
current_position: N/A

The debug log shows that MDT 0 sent an UPDATE_OBJ OBJ_ATTR_GET RPC to MDT 1. The FID was found in the OI but the ino was (naturally) stale:

00000004:00000002:0.0:1369882480.737242:0:7229:0:(osd_handler.c:226:osd_iget()) unmatched inode: ino = 102, gen0 = 2698313523, gen1 = 294820613

According to osd_fid_lookup(), OI scrubbing is not triggered in this case.

Whamcloud Community JIRA

[LU-3420] OI scrubbing could not automatically engage after restoring a secondary MDT from a (file-level) backup