Hi Tariq,
DATA=WRITEBACK:
From your words I understand that IF WE CAN ASSUME/TOLERATE A POSSIBLE
FILES CONTENTS "CORRUPTION" IN CASE OF FAILURE, this option IMPROVES
CLEARLY PERFORMANCE...right?
* I ask to you this cause, according mount.ocfs2 man page, this option
"is rumored to be the
On 09/16/2015 01:19 AM, Area de Sistemas wrote:
Hi Tariq,
DATA=WRITEBACK:
From your words I understand that IF WE CAN ASSUME/TOLERATE A POSSIBLE
FILES CONTENTS "CORRUPTION" IN CASE OF FAILURE, this option IMPROVES
CLEARLY PERFORMANCE...right?
* I ask to you this cause, according mount.ocfs2
Hi Area,
data=writeback improves things greatly. In ordered mode , the default,
before writing
a transaction(which only logs meta data changes) data is written. This
is very conservative
to ensure that before journal log buffer is written to disk journal
area, data has hit the disk and
Hi Tariq,
Yesterday one node was under load but not as high as past week, and
iostat showed:
- 10% of samples with %util >90% (some peaks of 100%) and an average
value of 18%
- %iowait peaks of 37% with an average value of 4%
BUT:
- none of the indicated error messages appeared in
On 09/14/2015 01:20 AM, Area de Sistemas wrote:
Hello everyone,
We have a problem in a 3 member OCFS2 cluster used to serve an web/php
application that access (read and/or write) files located in the OCFS2
volume.
The problem appears only some times (apparently during high load periods).
Hello everyone,
We have a problem in a 3 member OCFS2 cluster used to serve an web/php
application that access (read and/or write) files located in the OCFS2
volume.
The problem appears only some times (apparently during high load periods).
SYMPTOMS:
- access to OCFS2 content becomes more an
