<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>hmlth@t-hamel.fr<br><b>To: </b>"Krutika Dhananjay" <kdhananj@redhat.com><br><b>Cc: </b>gluster-users@gluster.org<br><b>Sent: </b>Tuesday, September 22, 2015 6:09:52 PM<br><b>Subject: </b>Re: [Gluster-users] "file changed as we read it" in gluster 3.7.4<br><div><br></div>On 2015-09-22 02:59, Krutika Dhananjay wrote:<br>> -------------------------<br>> <br>>> FROM: hmlth@t-hamel.fr<br>>> Thank you, this solved the issue (after a umount/mount). The<br>>> question<br>>> now is: what's the catch? Why is this not the default?<br>>> <br>>> https://partner-bugzilla.redhat.com/show_bug.cgi?id=1203122<br>>> <br>>> The above link makes me think that there is a problem with<br>>> "readdirp"<br>>> performances but I'm not sure if the impact is serious or not.<br>> <br>> That's right. Enabling the option can slow down readdirp operations,<br>> which is why it is disabled by default.<br><div><br></div>Is there a list of options where this tradeoff is being made? Disabling <br>consistency for performance is not what I was expecting by default.<br></blockquote><div>The rule consistent-metadata enforces is to always fetch attributes (in readdirp) from the _same_ brick in the replica set as long as it holds a good copy.<br></div><div>What this means is that _even_ if all replicas contain good copies of the file/directory, the replicate module will still fetch attributes from the default read child of the file/directory.<br></div><div>In fact the precise reason why consistent-metadata was introduced was to fix the tar bug you talk about. The reason for this is that due to clock skew, the replicas of a file will not have the same {c,m,a}time.<br></div><div>So enabling consistent-metadata would make sure that the attributes (specifically the ctime which tar program uses to determine whether a file changed while it was being archived) are consistently fetched from the same brick in the replica set.<br></div><div>But for this, there is no other issue consistent-metadata solves. The rest of the attributes would continue to be served from the good copy of the file in readdirp even if consistent-metadata is off.<br></div><div><br></div><div>The other option you have is to use the command line option '<span style="color: #222222; font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 16.9px; orphans: auto; text-align: left; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: #eeeeee;" data-mce-style="color: #222222; font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 16.9px; orphans: auto; text-align: left; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: #eeeeee;">--warning=no-file-changed</span>' while invoking the tar command to suppress these messages.<br></div><div><br></div><div>-Krutika<br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">Regards<br><div><br></div>Thomas HAMEL<br><div><br></div><br><div><br></div><br>>> <br>>> On 2015-09-21 16:14, Krutika Dhananjay wrote:<br>>>> Could you set 'cluster.consistent-metadata' to 'on' and try the<br>>> test<br>>>> again?<br>>>> <br>>>> #gluster volume set <VOL> cluster.consistent-metadata on<br>>>> <br>>>> -Krutika<br>>>> <br>>>> -------------------------<br>>>> <br>>>>> FROM: hmlth@t-hamel.fr<br>>>>> TO: gluster-users@gluster.org<br>>>>> SENT: Monday, September 21, 2015 7:10:59 PM<br>>>>> SUBJECT: [Gluster-users] "file changed as we read it" in gluster<br>>>>> 3.7.4<br>>>>> <br>>>>> Hello,<br>>>>> <br>>>>> I'm evaluating gluster on Debian, I installed the version 3.7.4<br>>> and<br>>>>> I<br>>>>> see this kind of error messages when I run tar:<br>>>>> <br>>>>> # tar c linux-3.16.7-ckt11/ > /dev/null<br>>>>> tar: linux-3.16.7-ckt11/sound/soc: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/net: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/Documentation/devicetree/bindings: file<br>>>>> changed<br>>>>> as we read it<br>>>>> tar: linux-3.16.7-ckt11/Documentation: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/tools/perf: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/include/uapi/linux: file changed as we<br>>> read<br>>>>> it<br>>>>> tar: linux-3.16.7-ckt11/arch/powerpc: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/arch/blackfin: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/arch/arm/boot/dts: file changed as we<br>>> read<br>>>>> it<br>>>>> tar: linux-3.16.7-ckt11/arch/arm: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/drivers/media: file changed as we read it<br>>>>> tar: linux-3.16.7-ckt11/drivers/staging: file changed as we read<br>>> it<br>>>>> #<br>>>>> <br>>>>> I saw this problem was discussed here earlier but I was under the<br>>>>> impression it was resolved on the 3.5 series. Is the fix in the<br>>> 3.7<br>>>>> branch?<br>>>>> <br>>>>> My volume configuration:<br>>>>> <br>>>>> # gluster volume info glustervol1<br>>>>> <br>>>>> Volume Name: glustervol1<br>>>>> Type: Replicate<br>>>>> Volume ID: 71ce34f2-28da-4674-91c9-b19a2b791aef<br>>>>> Status: Started<br>>>>> Number of Bricks: 1 x 3 = 3<br>>>>> Transport-type: tcp<br>>>>> Bricks:<br>>>>> Brick1: n1:/glusterfs/n1-2/brick<br>>>>> Brick2: n2:/glusterfs/n2-2/brick<br>>>>> Brick3: n3:/glusterfs/n3-2/brick<br>>>>> Options Reconfigured:<br>>>>> performance.readdir-ahead: on<br>>>>> cluster.server-quorum-ratio: 51<br>>>>> <br>>>>> Regards<br>>>>> <br>>>>> Thomas HAMEL<br>>>>> _______________________________________________<br>>>>> Gluster-users mailing list<br>>>>> Gluster-users@gluster.org<br>>>>> http://www.gluster.org/mailman/listinfo/gluster-users<br><div><br></div></blockquote><div><br></div></div></body></html>