<font size=2 face="sans-serif">Good point about "tiny" files
going into the inode and system pool. Which reminds one:</font><br><br><font size=2 face="sans-serif"> Generally a bad idea to
store metadata in wide striping disk base RAID (Type 5 with spinning media)
<br> Do use SSD or similar for metadata.</font><br><font size=2 face="sans-serif"> Consider smaller block
size for metadata / system pool than regular file data.</font><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Bryan Banister <bbanister@jumptrading.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">04/11/2018 12:51 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Confusing I/O Behavior</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>Just another thought here. If the debug output
files fit in an inode, then these would be handled as metadata updates
to the inode, which is typically much smaller than the file system blocksize.
Looking at my storage that handles GPFS metadata shows avg KiB/IO
at a horrendous 5-12 KiB!<br><br><br><br>HTH,<br><br>-B<br><br><br><br>-----Original Message-----<br><br>From: gpfsug-discuss-bounces@spectrumscale.org [</font></tt><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><tt><font size=2>mailto:gpfsug-discuss-bounces@spectrumscale.org</font></tt></a><tt><font size=2>]
On Behalf Of Peter Serocka<br><br>Sent: Wednesday, April 11, 2018 6:07 AM<br><br>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br><br>Subject: Re: [gpfsug-discuss] Confusing I/O Behavior<br><br><br><br>Note: External Email<br><br>-------------------------------------------------<br><br><br><br>Let’s keep in mind that line buffering is a concept<br><br>within the standard C library;<br><br>if every log line triggers one write(2) system call,<br><br>and it’s not direct io, then multiple write still get<br><br>coalesced into few larger disk writes (as with the dd example).<br><br><br><br>A logging application might choose to close(2)<br><br>a log file after each write(2) — that produces<br><br>a different scenario, where the file system might<br><br>guarantee that the data has been written to disk<br><br>when close(2) return a success.<br><br><br><br>(Local Linux file systems do not do this with default mounts,<br><br>but networked filesystems usually do.)<br><br><br><br>Aaron, can you trace your application to see<br><br>what is going on in terms of system calls?<br><br><br><br>— Peter<br><br><br><br><br><br>> On 2018 Apr 10 Tue, at 18:28, Marc A Kaplan <makaplan@us.ibm.com>
wrote:<br><br>><br><br>> Debug messages are typically unbuffered or "line buffered".
If that is truly causing a performance problem AND you still want
to collect the messages -- you'll need to find a better way to channel
and collect those messages.<br><br>><br><br>><br><br>> _______________________________________________<br><br>> gpfsug-discuss mailing list<br><br>> gpfsug-discuss at spectrumscale.org<br><br>> </font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=xSLLpVdHbkGieYfTGPIJRMkA1AbwsYteS2lHR4_49ik&s=9BOhyKNgkkbcOv316JZXnRB4HpPK_x2hyLd0d_uLGos&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=xSLLpVdHbkGieYfTGPIJRMkA1AbwsYteS2lHR4_49ik&s=9BOhyKNgkkbcOv316JZXnRB4HpPK_x2hyLd0d_uLGos&e=</font></tt></a><tt><font size=2><br><br><br><br>_______________________________________________<br><br>gpfsug-discuss mailing list<br><br>gpfsug-discuss at spectrumscale.org<br><br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=xSLLpVdHbkGieYfTGPIJRMkA1AbwsYteS2lHR4_49ik&s=9BOhyKNgkkbcOv316JZXnRB4HpPK_x2hyLd0d_uLGos&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=xSLLpVdHbkGieYfTGPIJRMkA1AbwsYteS2lHR4_49ik&s=9BOhyKNgkkbcOv316JZXnRB4HpPK_x2hyLd0d_uLGos&e=</font></tt></a><tt><font size=2><br><br><br><br>________________________________<br><br><br><br>Note: This email is for the confidential use of the named addressee(s)
only and may contain proprietary, confidential or privileged information.
If you are not the intended recipient, you are hereby notified that any
review, dissemination or copying of this email is strictly prohibited,
and to please notify the sender immediately and destroy this email and
any attachments. Email transmission cannot be guaranteed to be secure or
error-free. The Company, therefore, does not make any guarantees as to
the completeness or accuracy of this email or any attachments. This email
is for informational purposes only and does not constitute a recommendation,
offer, request or solicitation of any kind to buy, sell, subscribe, redeem
or perform any type of transaction of a financial product.<br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=xSLLpVdHbkGieYfTGPIJRMkA1AbwsYteS2lHR4_49ik&s=9BOhyKNgkkbcOv316JZXnRB4HpPK_x2hyLd0d_uLGos&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=xSLLpVdHbkGieYfTGPIJRMkA1AbwsYteS2lHR4_49ik&s=9BOhyKNgkkbcOv316JZXnRB4HpPK_x2hyLd0d_uLGos&e=</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>