LU-5044 mdd: do not return .lustre from readdir

In mdd_dir_page_build() skip dirents with the FID of .lustre
preventing that directory from being return by readdir on Lustre
clients. Add a sanity tets to this effect.

Signed-off-by: John L. Hammond <john.hammond@intel.com>
Change-Id: Ieecb77a286748c4bf4df4dee68d7f33670a0c286
Reviewed-on: http://review.whamcloud.com/11186
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: wangdi <di.wang@intel.com>
Tested-by: Maloo <hpdd-maloo@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.

This patch is back-ported from the following one:
Lustre-commit: 38ec486aeee20345a86dbbd2022d7976337c49b8
Lustre-change: http://review.whamcloud.com/11939

Signed-off-by: Patrick Farrell <paf@cray.com>
Change-Id: I509b960b111d12d6375c967163f50199cb8f76bf
Reviewed-on: http://review.whamcloud.com/12926
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
LU-5626 ldiskfs: update non-htree dotdot in rename

This mod duplicates changes previously committed only for el6
for sles11sp3.

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.

This patch is back-ported from the following one:
Lustre-commit: 4f8edadbbd3ba70d9236e98518182b4d3ff5acdb
Lustre-change: http://review.whamcloud.com/12585

Signed-off-by: Bob Glossman <bob.glossman@intel.com>
Change-Id: I1a51e85654837b9ce720ed925ccc4b90645f6e24
Reviewed-on: http://review.whamcloud.com/12927
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
LU-4958 lov: don't crash accessing LOV object with FID{0,0}

Some object maybe has a corrupted LOV EA or a hole in
LOV EA. We should not crash client in such case.

This is a back-port patch from master:
Lustre-change: http://review.whamcloud.com/10042
Lustre-commit: 754bf71c650c427acfb0fe35017e8f9c1eb9fa7d

Signed-off-by: Fan Yong <fan.yong@intel.com>
Signed-off-by: Yang Sheng <yang.sheng@intel.com>
Change-Id: I08cdd770c369eb51aa92b04a838fbb6784d36bad
Reviewed-on: http://review.whamcloud.com/12740
Tested-by: Jenkins
Reviewed-by: Jian Yu <jian.yu@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>