bea02e26a3
When a file is opened with append, all writes are appended at the end of file irrespective of the offset given in the write syscall. This needs to be considered in shard size update function and also for choosing which shard to write to. At the moment shard piggybacks on queuing from write-behind xlator for ordering of the operations. So if write-behind is disabled and two parallel appending-writes come both of which can increase the file size beyond shard-size the file will be corrupted. BUG: 1455301 Change-Id: I9007e6a39098ab0b5d5386367bd07eb5f89cb09e Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> Reviewed-on: https://review.gluster.org/17387 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Krutika Dhananjay <kdhananj@redhat.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
17 lines
428 B
Plaintext
17 lines
428 B
Plaintext
performance.quick-read=off
|
|
performance.read-ahead=off
|
|
performance.io-cache=off
|
|
performance.stat-prefetch=off
|
|
performance.open-behind=off
|
|
performance.readdir-ahead=off
|
|
network.remote-dio=enable
|
|
cluster.eager-lock=enable
|
|
cluster.quorum-type=auto
|
|
cluster.data-self-heal-algorithm=full
|
|
cluster.locking-scheme=granular
|
|
cluster.shd-max-threads=8
|
|
cluster.shd-wait-qlength=10000
|
|
features.shard=on
|
|
user.cifs=off
|
|
server.allow-insecure=on
|