summaryrefslogtreecommitdiffstats
path: root/AUTHORS
diff options
context:
space:
mode:
authorAnand Avati <avati@gluster.com>2010-11-09 05:27:02 +0000
committerAnand V. Avati <avati@dev.gluster.com>2010-11-09 03:07:07 -0800
commit6fb49f18a9bbfd1266b4773e757e459519c6719c (patch)
treefff8ff41717114ead7a7e2b848e83058d6d8b15a /AUTHORS
parent667c5e22467cbecd371bfc052e7f65b6b6b41e2d (diff)
replicate: optimistic changelog
The standard way of maintaining changelog in replicate has been to write out pending flags and to unset the pending flag post the actual operation. This new optimization kicks in only when all subvolumes are up. The optimization is that, during pre-op, no changelog is written for METADATA and ENTRY/RENAME operations. If during the operation nothing failed, no changelog is updated in post-op either. If however, something does fail during an operation, then, pending flags get written during post op pointing only towards the failed nodes. DATA transactions continue to work the way they are. If one subvolume is down, pending flags are written in pre-op changelog itself as before. The impact of this optimization is only in the case when both servers die or the client dies while the 'FOP' stage of the transaction is in progress. By nature of METADATA and ENTRY operations, detecting a mismatch later is not dependent on the presence of changelog. Changelog only determines the direction in which self-heal happens for these types of transactions. For the direction too this optimization does not have a major impact because in the cases of failure (both servers dieing or client dieing) the final state (direction of self-heal) would be arbitrary anyways as the syscall wouldn't have completed. Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 2068 (performance enhancements) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2068
Diffstat (limited to 'AUTHORS')
0 files changed, 0 insertions, 0 deletions