<div dir="ltr">While tuning can alleviate some pain it shouldn't go without mentioning that there are some operations that are just less than optimal on a parallel file system. I'd bet a cold one that a copy to local /tmp, vim/paste, copy back to the LFS would've been quicker. Some single-threaded small i/o operations can be approached more efficiently in a similar manner. <div><br></div><div>Lustre is a fantastic tool and like most tools it doesn't do everything well......*yet*</div><div><br></div><div>--Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 27, 2017 at 4:21 PM, Dilger, Andreas <span dir="ltr"><<a href="mailto:andreas.dilger@intel.com" target="_blank">andreas.dilger@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Apr 25, 2017, at 13:11, Bass, Ned <<a href="mailto:bass6@llnl.gov">bass6@llnl.gov</a>> wrote:<br>
><br>
> Hi Darby,<br>
><br>
>> -----Original Message-----<br>
>><br>
>> for i in $(seq 0 99) ; do<br>
>>   dd if=/dev/zero of=dd.dat.$i bs=1k count=1 conv=fsync > /dev/null 2>&1<br>
>> done<br>
>><br>
>> The timing of this ranges from 0.1 to 1 sec on our old LFS but ranges from 20<br>
>> to 60 sec on our newer 2.9 LFS.<br>
><br>
> Because Lustre does not yet use the ZFS Intent Log (ZIL), it implements fsync() by<br>
> waiting for an entire transaction group to get written out. This can incur long<br>
> delays on a busy filesystem as the transaction groups become quite large. Work<br>
> on implementing ZIL support is being tracked in LU-4009 but this feature is not<br>
> expected to make it into the upcoming 2.10 release.<br>
<br>
</span>There is also the patch that was developed in the past to test this:<br>
<a href="https://review.whamcloud.com/7761" rel="noreferrer" target="_blank">https://review.whamcloud.com/<wbr>7761</a> "LU-4009 osd-zfs: Add tunables to disable sync"<br>
which allows disabling ZFS to wait for TXG commit for each sync on the servers.<br>
<br>
That may be an acceptable workaround in the meantime.  Essentially, clients would<br>
_start_ a sync on the server, but would not wait for completion before returning<br>
to the application.  Both the client and the OSS would need to crash within a few<br>
seconds of the sync for it to be lost.<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Lustre Principal Architect<br>
Intel Corporation<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/<wbr>listinfo.cgi/lustre-discuss-<wbr>lustre.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">------------------------------<br>Jeff Johnson<br>Co-Founder<br>Aeon Computing<br><br><a href="mailto:jeff.johnson@aeoncomputing.com" target="_blank">jeff.johnson@aeoncomputing.com</a><br><a href="http://www.aeoncomputing.com" target="_blank">www.aeoncomputing.com</a><br>t: 858-412-3810 x1001   f: 858-412-3845<br>m: 619-204-9061<br><br>4170 Morena Boulevard, Suite D - San Diego, CA 92117<div><br></div><div>High-Performance Computing / Lustre Filesystems / Scale-out Storage</div></div></div>
</div>