doc: release-notes for GlusterFS-3.8.7v3.8.7

BUG: 1397911
Change-Id: I7522079ff9fb29588f0b3d716d89f88b04ab7b39
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/16104
Smoke: Gluster Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>

1 files changed, 76 insertions, 0 deletions

diff --git a/doc/release-notes/3.8.7.md b/doc/release-notes/3.8.7.md
new file mode 100644
index 00000000000..5a2fc980297
--- /dev/null
+++ b/doc/release-notes/3.8.7.md
@@ -0,0 +1,76 @@
+# Release notes for Gluster 3.8.7
+
+This is a bugfix release. The [Release Notes for 3.8.0](3.8.0.md),
+[3.8.1](3.8.1.md), [3.8.2](3.8.2.md), [3.8.3](3.8.3.md), [3.8.4](3.8.4.md),
+[3.8.5](3.8.5.md) and [3.8.6](3.8.6.md) contain a listing of all the new
+features that were added and bugs fixed in the GlusterFS 3.8 stable release.
+
+
+## New CLI option for granular entry heal enablement/disablement
+
+When there are already existing non-granular indices created that are yet to be
+healed, if granular-entry-heal option is toggled from `off` to `on`, AFR
+self-heal whenever it kicks in, will try to look for granular indices in
+`entry-changes`. Because of the absence of name indices, granular entry healing
+logic will fail to heal these directories, and worse yet unset pending extended
+attributes with the assumption that are no entries that need heal.
+
+To get around this, a new CLI is introduced which will invoke glfsheal program
+to figure whether at the time an attempt is made to enable granular entry heal,
+there are pending heals on the volume OR there are one or more bricks that are
+down. If either of them is true, the command will be failed with the
+appropriate error.
+
+    # gluster volume heal <VOL> granular-entry-heal {enable,disable}
+
+With this change, the user does not need to worry about when to enable/disable
+the option - the CLI command itself performs the necessary checks before
+allowing the "enable" command to proceed.
+
+What are those checks?
+* Whether heal is already needed on the volume
+* Whether any of the replicas is down
+
+In both of the cases, the command will be failed since AFR will be switching
+from creating heal indices (markers for files that need heal) under
+`.glusterfs/indices/xattrop` to creating them under
+`.glusterfs/indices/entry-changes`.
+The moment this switch happens, self-heal-daemon will cease to crawl the
+entire directory if a directory needs heal and instead looks for exact names
+under a directory that need heal under `.glusterfs/indices/entry-changes`. This
+might cause self-heal to miss healing some entries (because before the
+switch directories already needing heal won't have any indices under
+`.glusterfs/indices/entry-changes`) and mistakenly unset the pending heal
+xattrs even though the individual replicas are not in sync.
+
+When should users enable this option?
+* When they want to use the feature ;)
+* which is useful for faster self-healing in use cases with large number of
+  files under a single directory.
+  For example, it is useful in VM use cases with smaller shard sizes, given
+  that all shards are created under a single directory `.shard`. When a shard
+  is created while a replica was down, once it is back up, self-heal due to its
+  maintaining granular indices will know exactly which shard to recreate on the
+  sync as opposed to crawling the entire `.shard` directory to find out the
+  same information.
+
+
+## Bugs addressed
+
+A total of 16 patches have been merged, addressing 15 bugs:
+
+- [#1395652](https://bugzilla.redhat.com/1395652): ganesha-ha.conf --status should validate if the VIPs are assigned to right nodes
+- [#1397663](https://bugzilla.redhat.com/1397663): libgfapi core dumps
+- [#1398501](https://bugzilla.redhat.com/1398501): [granular entry sh] - Provide a CLI to enable/disable the feature that checks that there are no heals pending before allowing the operation
+- [#1399018](https://bugzilla.redhat.com/1399018): performance.read-ahead on results in processes on client stuck in IO wait
+- [#1399088](https://bugzilla.redhat.com/1399088): geo-replica slave node goes faulty for non-root user session due to fail to locate gluster binary
+- [#1399090](https://bugzilla.redhat.com/1399090): [geo-rep]: Worker crashes seen while renaming directories in loop
+- [#1399130](https://bugzilla.redhat.com/1399130): SEEK_HOLE/ SEEK_DATA doesn't return the correct offset
+- [#1399635](https://bugzilla.redhat.com/1399635): Refresh config fails while exporting subdirectories within a volume
+- [#1400459](https://bugzilla.redhat.com/1400459): [USS,SSL] .snaps directory is not reachable when I/O encryption (SSL) is enabled
+- [#1400573](https://bugzilla.redhat.com/1400573): Ganesha services are not stopped when pacemaker quorum is lost
+- [#1400802](https://bugzilla.redhat.com/1400802): glusterfs_ctx_defaults_init is re-initializing ctx->locks
+- [#1400927](https://bugzilla.redhat.com/1400927): Memory leak when self healing daemon queue is full
+- [#1402672](https://bugzilla.redhat.com/1402672): Getting the warning message while erasing the gluster "glusterfs-server" package.
+- [#1403192](https://bugzilla.redhat.com/1403192): Files remain unhealed forever if shd is disabled and re-enabled while healing is in progress.
+- [#1403646](https://bugzilla.redhat.com/1403646): self-heal not happening, as self-heal info lists the same pending shards to be healed