Whamcloud - gitweb
LU-7782 scrub: handle slave obj of striped directory 06/21506/5
authorFan Yong <fan.yong@intel.com>
Fri, 17 Jun 2016 22:50:02 +0000 (06:50 +0800)
committerOleg Drokin <oleg.drokin@intel.com>
Sat, 10 Sep 2016 03:23:21 +0000 (03:23 +0000)
commit842bda9c5b41eef9e43dc3e00f05767147611677
tree3475def60c7af82aa2b1f2857f441ceac184a173
parent1cb9e85039c8df5fbe061aad3b0666c59ff7aa4e
LU-7782 scrub: handle slave obj of striped directory

When lookup item under striped directory, we need to locate the
master MDT-object of the striped directory firstly, then the
client will send lookup (getattr_by_name) RPC to the MDT with
some slave MDT-object's FID and the item's name. If the system
is restored from MDT file level backup, then before the OI scrub
completely built the OI files, the OI mappings of the master
MDT-object and slave MDT-object may be invalid. Usually, it is
not a problem for the master MDT-object. Because when locate the
master MDT-object, we will do name based lookup (for the striped
directory itself) firstly, during such process we can setup the
correct OI mapping for the master MDT-object. But it will be
trouble for the slave MDT-object. Because the client will not
trigger name based lookup on the MDT to locate the slave
MDT-object before locating item under the striped directory,
then when osd_fid_lookup(), it will find that the OI mapping
for the slave MDT-object is invalid and does not know what the
right OI mapping is, then the MDT has to return -EINPROGRESS to
the client to notify that the OI scrub is rebuiding the OI file,
related OI mapping is unknown yet, please try again later. And
then client will re-try the RPC again and again until related
OI mapping has been updated. That is quite inefficient.

To resolve above trouble, we will handle it as the following
two cases:

1) The slave MDT-object and the MDT-object are on different
   MDTs. It is relative easy. Be as one of remote MDT-objects,
   the slave MDT-object is linked under /REMOTE_PARENT_DIR
   with the name of its FID string. We can locate the slave
   MDT-object via lookup the /REMOTE_PARENT_DIR directly.

2) The slave MDT-object and the MDT-object reside on the same
   MDT. Under such case, during lookup the master MDT-object,
   we will lookup the slave MDT-object via readdir the master
   MDT-object, because the slave MDT-objects information are
   stored as sub-directories with the name "${FID}:${index}".
   Then when find the local slave MDT-object, its OI mapping
   will be recorded. Then subsequent osd_fid_lookup() will
   know the correct OI mapping for the slave MDT-object.

The patch also fix a race between osd_fid_lookup and OI scrub:
the OI scrub thread will remove osd_inconsistent_item from the
global list before updating related OI mapping, and if someone
call osd_fid_lookup() for the OI mapping during such interval,
it will get failure and trigger full mode OI scrub by wrong.

The patch also enhance sanity-scrub to avoid DNE in sanity-scrub
on one MDT.

Test-Parameters: mdtfilesystemtype=ldiskfs mdsfilesystemtype=ldiskfs ostfilesystemtype=ldiskfs mdscount=2 mdtcount=4 testlist=sanity-scrub,sanity-scrub,sanity-scrub
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I6b449ef86221410dfc16005a586ed140b9a48b38
Reviewed-on: http://review.whamcloud.com/21506
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
lustre/osd-ldiskfs/osd_compat.c
lustre/osd-ldiskfs/osd_handler.c
lustre/osd-ldiskfs/osd_scrub.c
lustre/tests/sanity-scrub.sh