LU-5727 ldlm: revert changes to ldlm_cancel_aged_policy()

The changes to ldlm_cancel_aged_policy() intrdouced from LU-4300
(bfae5a) was incorrect. This patch revert this part of changes.

Signed-off-by: Niu Yawei <yawei.niu@intel.com>
Change-Id: Ic04f894c8bf54dbbdfb0e3bada5f6e4a367711a5
Reviewed-on: http://review.whamcloud.com/12448
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5517 lfsck: repair invalid nlink count

If the namespace LFSCK has verified all the known name entries during
the first-stage scanning, then the MDT-object's linkEA is trustable.
So if the non-directory MDT-object's nlink attribute does not match
the MDT-object linkEA entries count, then the LFSCK will repair the
MDT-object's nlink attribute according to its linkEA entries count.

One exception is that: the linkEA space is limited, if there are too
much hard links on the MDT-object and exceeds the object's linkEA
space limitation, then some name entries cannot be recorded in the
linkEA. Under such case, we will add some flags (LLF_SKIP_NLINK)
in the LFSCK tracing file for related MDT-objects. Then the LFSCK
can skip the nlink attribute verification for the marked MDT-objects
during the second-stage scanning.

This patch also cleanup the LFSCK environment when current LFSCK
scanning exits (completed/stopped/failed) to avoid some stale to
misguide the next LFSCK scanning.

This patch also makes some code adjustment for the former landed
LFSCK patches according to the inspection feedback.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Iedc676e8cc06a52f55e82372e6dc8b30008e20f4
Reviewed-on: http://review.whamcloud.com/11516
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5518 lfsck: recover orphans from backend lost+found

Some local filesystem consistency verification tools, such as
e2fsck for ldiskfs, will add the orphan objects under backend
special /lost+found directory. Such directory is invisible to
clients. The namespace LFSCK will scan such directory, and for
the objects that were visible to clients originally (according
to the FID), the namespace LFSCK will move them back to the
normal namespace (according to the linkEA) or to the global
visible .lustre/lost+found/MDTxxxx/ directory.

The namespace LFSCK will insert the orphan (that is under the
backend /lost+found directory) FID into the namespace LFSCK
tracing file for further processing (via the subsequent namespace
LFSCK second-stage scanning). At the same time, remove the orphan
name entry from backend /lost+found directory. There is an interval
between the orphan name entry removed from the backend /lost+found
directory and the orphan FID in the LFSCK tracing file handled. In
such interval, the LFSCK can be reset, then all the FIDs recorded
in the namespace LFSCK tracing file will be dropped. To guarantee
that the orphans can be found when LFSCK run next time without
e2fsck again, when remove the orphan name entry, the LFSCK will
set the orphan's ctime attribute as 1. Since normal applications
cannot change the object's ctime attribute as 1. Then when LFSCK
run next time, it can record the object (that ctime is 1) in the
namespace LFSCK tracing file during the first-stage scanning. Once
the FID in the LFSCK tracing file has been handled successfully,
then the object's ctime attribute will be changed to normal time.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I2f8e23801a868f2c99c630face4bbfe08ece8844
Reviewed-on: http://review.whamcloud.com/11536
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5519 lfsck: LFSCK code framework adjustment (2)

Enhance LFSCK code framework for striped directory verification,
including:

1) New lfsck component APIs: lfsck_operations::lfsck_open_dir()
   and lfsck_operations::lfsck_close_dir().
1.1) The namespace LFSCK uses lfsck_open_dir() to initialize the
     LMV EA verification environment.
1.2) The namespace LFSCK uses lfsck_close_dir() to indicate the
     end of the scanning the striped directory.

2) When create orphan parent, the LMV EA should be considered.

3) Data structure definition and extention.

4) Other code cleanup.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I01e14645796c3fa3269c5f3cdcbb755ccb455d7e
Reviewed-on: http://review.whamcloud.com/11845
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5675 quota: correctly set II_FL_NONUNQ in dt_index_read()

Fix regression introduced by 60e07b972114df24105a3a1bfa7365892f72a4a7
II_FL_NONUNQ should be set in the index information only when the
backend index supports DT_IND_NONUNQ.
This mistake triggers the following warning in the qsd code:

Lustre: 25029:0:(qsd_reint.c:237:qsd_reint_index()) lustre-MDT0000:
II_FL_NONUNQ is set on index transfer for fid
[0x200000005:0x1011:0x0], it shouldn't be

Signed-off-by: Johann Lombardi <johann.lombardi@intel.com>
Change-Id: I42a9c70666c741064b356ffd253b49e5ed7b3e93
Reviewed-on: http://review.whamcloud.com/12074
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: wangdi <di.wang@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5626 ldiskfs: update non-htree dotdot in rename

In 2.4+, when renaming a directory, its old dotdot entry will
be removed firstly, then the new dotdot entry is inserted, and
ldiskfs tries to append FID-in-dirent to the new entry.
But the space for dotdot entry may not be enough to hold
the new dotdot with FID-in-dirent, such as an MDT device
restored from file-level backup, or a device upgraded from 1.8.

In that case, for non-HTree directories, the ".." entry
will be written in the next available space in the directory
block.  This is invalid, as the ".." entry must be the
second entry in the block.

The same bug was fixed for HTree directories in LU-2638.
As Fan Yong said then: we do not want to introduce
complex logic to handle directory data moving, instead, in
such case, ignore the FID-in-dirent for the new dotdot entry,
and just insert the new dotdot entry.

There is one known flaw: This patch, like the one for
LU-2638, skips the entire data section rather than just
the FID.  This could cause trouble if something else ever
uses this section with ".." entries.

Signed-off-by: Patrick Farrell <paf@cray.com>
Change-Id: I57fc492e694973f5020191e4e2c79c74c7c4f18c
Reviewed-on: http://review.whamcloud.com/11939
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Jenkins
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Tested-by: Maloo <hpdd-maloo@intel.com>