[gpfsug-discuss] Confusing I/O Behavior
Marc A Kaplan
makaplan at us.ibm.com
Wed Apr 11 18:23:02 BST 2018
Good point about "tiny" files going into the inode and system pool. Which
reminds one:
Generally a bad idea to store metadata in wide striping disk base RAID
(Type 5 with spinning media)
Do use SSD or similar for metadata.
Consider smaller block size for metadata / system pool than regular
file data.
From: Bryan Banister <bbanister at jumptrading.com>
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date: 04/11/2018 12:51 PM
Subject: Re: [gpfsug-discuss] Confusing I/O Behavior
Sent by: gpfsug-discuss-bounces at spectrumscale.org
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!
HTH,
-B
-----Original Message-----
From: gpfsug-discuss-bounces at spectrumscale.org [
mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Peter
Serocka
Sent: Wednesday, April 11, 2018 6:07 AM
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] Confusing I/O Behavior
Note: External Email
-------------------------------------------------
Let’s keep in mind that line buffering is a concept
within the standard C library;
if every log line triggers one write(2) system call,
and it’s not direct io, then multiple write still get
coalesced into few larger disk writes (as with the dd example).
A logging application might choose to close(2)
a log file after each write(2) — that produces
a different scenario, where the file system might
guarantee that the data has been written to disk
when close(2) return a success.
(Local Linux file systems do not do this with default mounts,
but networked filesystems usually do.)
Aaron, can you trace your application to see
what is going on in terms of system calls?
— Peter
> On 2018 Apr 10 Tue, at 18:28, Marc A Kaplan <makaplan at us.ibm.com> wrote:
>
> 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.
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
>
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=
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
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=
________________________________
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.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
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=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180411/fd13e4d2/attachment-0002.htm>
More information about the gpfsug-discuss
mailing list