From 076830c068fb39bbc3e863c89a4253cbea36357e Mon Sep 17 00:00:00 2001 From: Vijay Bellur Date: Mon, 9 Apr 2012 23:11:52 +0530 Subject: doc: Move outdated documentation to legacy Change-Id: I0ceba9a993e8b1cdef4ff6a784bfd69c08107d88 BUG: 811311 Signed-off-by: Vijay Bellur Reviewed-on: http://review.gluster.com/3116 Tested-by: Gluster Build System Reviewed-by: Amar Tumballi Reviewed-by: Anand Avati --- doc/legacy/hacker-guide/write-behind.txt | 45 ++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 doc/legacy/hacker-guide/write-behind.txt (limited to 'doc/legacy/hacker-guide/write-behind.txt') diff --git a/doc/legacy/hacker-guide/write-behind.txt b/doc/legacy/hacker-guide/write-behind.txt new file mode 100644 index 000000000..50b7d2a1d --- /dev/null +++ b/doc/legacy/hacker-guide/write-behind.txt @@ -0,0 +1,45 @@ +basic working +-------------- + + write behind is basically a translator to lie to the application that the write-requests are finished, even before it is actually finished. + + on a regular translator tree without write-behind, control flow is like this: + + 1. application makes a write() system call. + 2. VFS ==> FUSE ==> /dev/fuse. + 3. fuse-bridge initiates a glusterfs writev() call. + 4. writev() is STACK_WIND()ed upto client-protocol or storage translator. + 5. client-protocol, on receiving reply from server, starts STACK_UNWIND() towards the fuse-bridge. + + on a translator tree with write-behind, control flow is like this: + + 1. application makes a write() system call. + 2. VFS ==> FUSE ==> /dev/fuse. + 3. fuse-bridge initiates a glusterfs writev() call. + 4. writev() is STACK_WIND()ed upto write-behind translator. + 5. write-behind adds the write buffer to its internal queue and does a STACK_UNWIND() towards the fuse-bridge. + + write call is completed in application's percepective. after STACK_UNWIND()ing towards the fuse-bridge, write-behind initiates a fresh writev() call to its child translator, whose replies will be consumed by write-behind itself. write-behind _doesn't_ cache the write buffer, unless 'option flush-behind on' is specified in volume specification file. + +windowing +--------- + + write respect to write-behind, each write-buffer has three flags: 'stack_wound', 'write_behind' and 'got_reply'. + + stack_wound: if set, indicates that write-behind has initiated STACK_WIND() towards child translator. + + write_behind: if set, indicates that write-behind has done STACK_UNWIND() towards fuse-bridge. + + got_reply: if set, indicates that write-behind has received reply from child translator for a writev() STACK_WIND(). a request will be destroyed by write-behind only if this flag is set. + + currently pending write requests = aggregate size of requests with write_behind = 1 and got_reply = 0. + + window size limits the aggregate size of currently pending write requests. once the pending requests' size has reached the window size, write-behind blocks writev() calls from fuse-bridge. + blocking is only from application's perspective. write-behind does STACK_WIND() to child translator straight-away, but hold behind the STACK_UNWIND() towards fuse-bridge. STACK_UNWIND() is done only once write-behind gets enough replies to accomodate for currently blocked request. + +flush behind +------------ + + if 'option flush-behind on' is specified in volume specification file, then write-behind sends aggregate write requests to child translator, instead of regular per request STACK_WIND()s. + + -- cgit