LU-4974 doc: comments to lod_qos.c

The comments to the functions in doxygen style.

Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Change-Id: I2224170759b9bfb852b467c4950a6d0c73374d53
Reviewed-on: http://review.whamcloud.com/11138
Reviewed-by: Richard Henwood <richard.henwood@intel.com>
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
LU-4975 ofd: documenting ofd_io.c

Fix up GPL header block to reference proper GPLv2 license URL.
Remove mention of contacting Sun, since they don't exist anymore.
Add introductory comment block for the ofd_io.c file and add
function comment blocks to all functions in it.

Signed-off-by: Mikhail Pershin <mike.pershin@intel.com>
Change-Id: Ic45e8a53f6df127c815f332ef2f5e219506727aa
Reviewed-on: http://review.whamcloud.com/11156
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
LU-5511 lfsck: repair unmatched parent-child pairs

If the parent directry_A reference the child directory_B via the
name entry_C, but the child directory_B back references another
parent directory_D via its ".." name entry, then the namespace
LFSCK should can find out such inconsistency in the second-stage
scanning and repair it by trusting the name entry_B basically.

Usually, for local filesystem or Lustre backend system, such as
ldiskfs, the local filesystem consistency verification tools,
such as e2fsck can guarantee such consistency. So the namespace
LFSCK will mainly focus on the corss-MDTs parent-child pairs
consistency verification.

Lustre does not support hardlink on directory object. So if the
directory contains multiple linkEA entries or bad linkEA entry,
then the namespace LFSCK should can find out and repair related
inconsistency.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: If8cb02f76329fe04fe3a6c280e6926d014654322
Reviewed-on: http://review.whamcloud.com/11486
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5512 lfsck: repair dangling name entry

If the MDT-object referenced by the name entry is lost, then the
namespace LFSCK needs to repair the inconsistency as required:

1) Keep the inconsistency there and report the inconsistency case,
   then give the chance to the application to find related issues,
   and the users can make the decision about how to handle it with
   more human knownledge. (by default)

2) Re-create the missed MDT-object with the FID (in the name entry)

The LFSCK will allow the administrator to specify how to handle the
dangling name entry via a new option "-C" when trigger the LFSCK:

[-Coff] or [--create_mdtobj=off]:
Report the inconsistency via log, but keep the dangling name entry
there without repairing. (by default)

-C[on] or --create_mdtobj[=on]:
Create the lost MDT-object.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I78231914023b8d02daf4f6cde6176c1ef655f862
Reviewed-on: http://review.whamcloud.com/11330
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>