glusterfs.git/xlators/performance/write-behind, branch v3.7.12

performance/write-behind: guaranteed retry after a short write

2016-05-05T03:27:33+00:00

* Don't mark the request with a fake EIO after a short write.
* retry the remaining buffer at least once before unwinding reply to
  application. This way we capture correct error from backend (ENOSPC,
  EDQUOT etc).

Thanks to "Vijaikumar Mallikarjuna" for the test
script.

Change-Id: I73a18b39b661a7424db1a7855a980469a51da8f9
BUG: 1332790
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/14196
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

performance/write-behind: retry "failed syncs to backend"

2016-02-16T09:09:34+00:00

1. When sync fails, the cached-write is still preserved unless there
   is a flush/fsync waiting on it.

2. When a sync fails and there is a flush/fsync waiting on the
   cached-write, the cache is thrown away and no further retries will
   be made. In other words flush/fsync act as barriers for all the
   previous writes. The behaviour of fsync acting as a barrier is
   controlled by an option (see below for details). All previous
   writes are either successfully synced to backend or forgotten in
   case of an error. Without such barrier fop (especially flush which
   is issued prior to a close), we end up retrying for ever even after
   fd is closed.

3. If a fop is waiting on cached-write and syncing to backend fails,
   the waiting fop is failed.

4. sync failures when no fop is waiting are ignored and are not
   propagated to application. For eg.,
   a. first attempt of sync of a cached-write w1 fails
   b. second attempt of sync of w1 succeeds

   If there are no fops dependent on w1 are issued b/w a and b,
   application won't know about failure encountered in a.

5. The effect of repeated sync failures is that, there will be no
   cache for future writes and they cannot be written behind.

fsync as a barrier and resync of cached writes post fsync failure:
==================================================================
Whether to keep retrying failed syncs post fsync is controlled by an
option "resync-failed-syncs-after-fsync". By default, this option is
set to "off".

If sync of "cached-writes issued before fsync" (to backend) fails,
this option configures whether to retry syncing them after fsync or
forget them. If set to on, cached-writes are retried till a "flush"
fop (or a successful sync) on sync failures. fsync itself is failed
irrespective of the value of this option, when there is a sync failure
of any cached-writes issued before fsync.

Change-Id: I6097c0257bfb9ee5b1f616fbe6a0576ae9af369a
Signed-off-by: Raghavendra G 
BUG: 1293534
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/13057
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

Logging: Porting the performance translator

2015-06-29T09:21:53+00:00

         logs to new logging framework

> Change-Id: Ie6aaf8d30bd4457bb73c48e23e6b1dea27598644
> BUG: 1194640
> Signed-off-by: arao 

BUG: 1217722
Change-Id: I0856c43dbf8c0a1aa084d4478c9bdf3f41dfc0b8
Signed-off-by: arao 
Reviewed-on: http://review.gluster.org/11442
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

build: MacOSX Porting fixes

2014-04-24T21:41:48+00:00

git@forge.gluster.org:~schafdog/glusterfs-core/osx-glusterfs

Working functionality on MacOSX

 - GlusterD (management daemon)
 - GlusterCLI (management cli)
 - GlusterFS FUSE (using OSXFUSE)
 - GlusterNFS (without NLM - issues with rpc.statd)

Change-Id: I20193d3f8904388e47344e523b3787dbeab044ac
BUG: 1089172
Signed-off-by: Harshavardhana 
Signed-off-by: Dennis Schafroth 
Tested-by: Harshavardhana 
Tested-by: Dennis Schafroth 
Reviewed-on: http://review.gluster.org/7503
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

write-behind: track filesize when doing extending writes

2014-02-28T05:56:48+00:00

A program that calls mmap() on a newly created sparse file, may receive
a SIGBUS signal. If SIGBUS is not handled, a segmentation fault will
occur and the program will exit.

A bug in the write-behind translator can cause the creation of a sparse
file created with open(), seek(), write() to be cached. The last write()
may not be sent to the server, until write-behind deems this necessary.

* open(.., O_TRUNC, ...)/creat() the file, it is 0 bytes big
* seek() into the file, use offset 31
* write() 1 byte to the file
* the range from byte 0-30 are unwritten so called 'sparse'

The following illustration tries to capture this:

    Legend:
    [ = start of file
    _ = unallocated/unwritten bytes
    # = allocated bytes in the file
    ] = end of file

    [_______________#]
     |              |
     '- byte 0      '- byte 31

Without this change, reading from byte 0-30 will return an error, and
reading the same area through an mmap()'d pointer will trigger a SIGBUS.
Reading from this range did not trigger the outstanding write() to be
flushed. The brick that receives the read() (translated over the network
from mmap()) does not know that the file has been extended, and returns
-EINVAL. This error gets transported back from the brick to the
glusterfs-fuse client, and translated by the Linux kernel/VFS into
SIGBUS triggered by mmap().

In order to solve this, a new attribute to the wb_inode structure is
introduced; the current size of the file. All FOPs that can modify the
size, are expected to update wb_inode->size. This makes it possible for
extending writes with an offset bigger than EOF to mark the unwritten
area as modified/pending.

Change-Id: If5ba6646732e6be26568541ea9b12852a5d0b988
BUG: 1058663
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/6835
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Reviewed-by: Anand Avati

Fix for 'use after free' errors reported by coverity.

2014-02-06T06:09:13+00:00

Change-Id: I941fc89b2d696c7f227330321ed4bba3ed1deac4
BUG: 789278
Signed-off-by: Poornima 
Reviewed-on: http://review.gluster.org/6868
Reviewed-by: Raghavendra G 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

write-behind: handle iobref_merge() error gracefully

2013-11-26T18:32:00+00:00

.. by UNWINDing ENOMEM error, rather than crashing.

Change-Id: Ica2d6399eaf7e381e7ebc41155620559c139c4d3
BUG: 1034398
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/6349
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

performance/write-behind: invoke request queue processing if

2013-08-14T09:11:58+00:00

we find fd marked bad while trying to fulfill lies.

* flush was queued behind some unfulfilled write.
* A previously wound write returned an error and hence fd was marked
  bad with corresponding error.
* wb_fulfill_head (invocation probably rooted in wb_flush), before
  winding checks for failures of previous writes and since there was a
  failure, calls wb_head_done without even winding one request in head.
* wb_head_done unrefs all the requests in list "head".
* since flush was last operation on fd (and most likely last operation
  on inode itself), no one invokes wb_process_queue and flush is stuck
  in request queue for eternity.

Change-Id: I3b5b114a1c401d477dd7ff64fb6119b43fda2d18
BUG: 988642
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/5398
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

write-behind: preserve error returned as-is

2013-07-25T01:39:13+00:00

Change-Id: Ib766403774c1323e0bbddafedeaa47e7fa3a59fa
Signed-off-by: Amar Tumballi 
BUG: 987415
Reviewed-on: http://review.gluster.org/5296
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

performance/write-behind: Enable write-behind when strict_O_DIRECT is not set.

2013-05-28T17:05:28+00:00

When open() with O_DIRECT happens, write-behind was being disabled for the
fd irrespective of strict_O_DIRECT option. This commit disables write-behind
only when strict_O_DIRECT is enabled.

Change-Id: Ieef180e52910c3bf64d46b26b0e5dc3b8542f6d2
BUG: 923556
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/4697
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy