<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>
<div>We have a gluster pool where our developers are writing large files with the suffix .COPYING, then removing that suffix when the copy is done (renaming the file), so consumers of the data know the file is safe to read.</div>
<div><br>
</div>
<div>Back in 2014, Jeff Darcy wrote the below in a thread. I guess I am basically asking if this is still the supported/encouraged approach, and how do I implement this when I’m using gluster’s NFS?</div>
<div><br>
</div>
<div>"<span style="font-family: -webkit-standard;">That said, there's also a trick you can use to avoid creation of a</span></div>
<div style="font-family: -webkit-standard;">linkfile. Other tools, such as rsync and our own object interface,</div>
<div style="font-family: -webkit-standard;">use the same write-then-rename idiom. To serve them, there's an</div>
<div style="font-family: -webkit-standard;">option called extra-hash-regex that can be used to place files on the</div>
<div style="font-family: -webkit-standard;">"right" brick according to their final name even though they're created</div>
<div style="font-family: -webkit-standard;">with another. Unfortunately, specifying that option via the command line</div>
<div style="font-family: -webkit-standard;">doesn't seem to work (it creates a malformed volfile) so you have to</div>
<div style="font-family: -webkit-standard;">mount a bit differently. For example:</div>
<div style="font-family: -webkit-standard;"><br>
</div>
<div style="font-family: -webkit-standard;"> glusterfs --volfile-server=a_server --volfile-id=a_volume \</div>
<div style="font-family: -webkit-standard;"> --xlator-option a_volume-dht.extra_hash_regex='(.*+)tmp' \</div>
<div style="font-family: -webkit-standard;"> /a/mountpoint</div>
<div style="font-family: -webkit-standard;"><br>
</div>
<div style="font-family: -webkit-standard;">The important part is that second line. That causes any file with a</div>
<div style="font-family: -webkit-standard;">"tmp" suffix to be hashed and placed as though only the part in the</div>
<div style="font-family: -webkit-standard;">first parenthesized part of the regex (i.e. without the "tmp") was</div>
<div style="font-family: -webkit-standard;">there. Therefore, creating "xxxtmp" and then renaming it to "xxx" is</div>
<div style="font-family: -webkit-standard;">the same as just creating "xxx" in the first place as far as linkfiles</div>
<div style="font-family: -webkit-standard;">etc. are concerned. Note that the excluded part can be anything that</div>
<div style="font-family: -webkit-standard;">a regex can match, including a unique random number. If I recall,</div>
<div style="font-family: -webkit-standard;">rsync uses temp files something like this:</div>
<div style="font-family: -webkit-standard;"><br>
</div>
<div style="font-family: -webkit-standard;"> fubar = .fubar.NNNNNN (where NNNNNNN is a random number)</div>
<div style="font-family: -webkit-standard;"><br>
</div>
<div style="font-family: -webkit-standard;">I know this probably seems a little voodoo-ish, but with a little bit</div>
<div style="font-family: -webkit-standard;">of experimentation to find the right regex you should be able to avoid</div>
<div style="font-family: -webkit-standard;">those dreaded linkfiles altogether."</div>
</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
</div>
</body>
</html>