Rename in_progress to under_review

`in_progress` is vague term, which could either mean the feature
review is in progress, or that the feature implementation is in
progress.

Renaming to `under_review` gives a much better indication that the
feature is under review and implementation hasn't begun yet.

Refer https://review.gluster.org/13187 for the discussion which
lead to this

Change-Id: I3f48e15deb4cf5486d7b8cac4a7915f9925f38f5
Signed-off-by: Kaushal M <kshlmster@gmail.com>
Reviewed-on: http://review.gluster.org/13264
Reviewed-by: Raghavendra Talur <rtalur@redhat.com>
Tested-by: Raghavendra Talur <rtalur@redhat.com>

1 files changed, 0 insertions, 143 deletions

diff --git a/in_progress/caching.md b/in_progress/caching.md
deleted file mode 100644
index 2c21c0c..0000000
--- a/in_progress/caching.md
+++ /dev/null
@@ -1,143 +0,0 @@
-Goal Caching
-------------
-
-Improved performance via client-side caching.
-
-Summary
--------
-
-GlusterFS has historically taken a very conservative approach to
-client-side caching, due to the cost and difficulty of ensuring
-consistency across a truly distributed file system. However, this has
-often led to a competitive disadvantage vs. other file systems that
-cache more aggressively. While one could argue that expecting an
-application designed for a local FS or NFS to behave the same way on a
-distributed FS is unrealistic, or question whether competitors' caching
-is really safe, this nonetheless remains one of our users' top requests.
-
-For purposes of this discussion, pre-fetching into cache is considered
-part of caching itself. However, write-behind caching (buffering) is a
-separate feature, and is not in scope.
-
-Owners
-------
-
-Xavier Hernandez <xhernandez@datalab.es>
-
-Jeff Darcy <jdarcy@redhat.com>
-
-Current status
---------------
-
-Proposed, waiting until summit for approval.
-
-Related Feature Requests and Bugs
----------------------------------
-
-[Features/FS-Cache](Features/FS-Cache "wikilink") is about a looser
-(non-consistent) kind of caching integrated via FUSE. This feature is
-differentiated by being fully consistent, and implemented in GlusterFS
-itself.
-
-[IMCa](http://mvapich.cse.ohio-state.edu/static/media/publications/slide/imca_icpp08.pdf)
-describes a completely external approach to caching (both data and
-metadata) with GlusterFS.
-
-Detailed Description
---------------------
-
-Retaining data in cache on a client after it's read is trivial.
-Pre-fetching into that same cache is barely more difficult. All of the
-hard parts are on the server.
-
--   Tracking which clients still have cached copies of which data (or
-    metadata).
-
--   Issuing and waiting for invalidation requests when a client changes
-    data cached elsewhere.
-
--   Handling failures of the servers tracking client state, and of
-    communication with clients that need to be invalidated.
-
--   Doing all of this without putting performance in the toilet.
-
-Invalidating cached copies is analogous to breaking locks, so the
-async-notification and "oplock" code already being developed for
-multi-protocol (SMB3/NFS4) support can probably be used here. More
-design is probably needed around scalable/performant tracking of client
-cache state by servers.
-
-Benefit to GlusterFS
---------------------
-
-Much better performance for cache-friendly workloads.
-
-Scope
------
-
-### Nature of proposed change
-
-Some of the existing "performance" translators could be replaced by a
-single client-caching translator. There will also need to be a
-server-side helper translator to track client cache states and issue
-invalidation requests at the appropriate times. Such asynchronous
-(server-initiated) requests probably require transport changes, and
-[GF\_FOP\_IPC](http://review.gluster.org/#/c/8812/) might play a part as
-well.
-
-### Implications on manageability
-
-New commands will be needed to set cache parameters, force cache
-flushes, etc.
-
-### Implications on presentation layer
-
-None, except for integration with the same async/oplock infrastructure
-as used separately in SMB and NFS.
-
-### Implications on persistence layer
-
-None.
-
-### Implications on 'GlusterFS' backend
-
-We will likely need some sort of database associated with each brick to
-maintain information about cache states.
-
-### Modification to GlusterFS metadata
-
-None.
-
-### Implications on 'glusterd'
-
-None.
-
-How To Test
------------
-
-We'll need new tests to verify that invalidations are in fact occurring,
-that we can't read stale/inconsistent data despite the increased caching
-on clients, etc.
-
-User Experience
----------------
-
-See "implications on manageability" section.
-
-Dependencies
-------------
-
-Async-notification and oplock code from the Samba team.
-
-Documentation
--------------
-
-TBD
-
-Status
-------
-
-Design in private review, hopefully available for public review soon.
-
-Comments and Discussion
------------------------