From: Gionatan Danti <g.danti@assyoma.it>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org, g.danti@assyoma.it
Subject: Re: Block size and read-modify-write
Date: Thu, 04 Jan 2018 02:38:04 +0100 [thread overview]
Message-ID: <cbb5ecb1dac9d6c26ce9bede5424cedc@assyoma.it> (raw)
In-Reply-To: <20180103225954.GP5858@dastard>
Il 03-01-2018 23:59 Dave Chinner ha scritto:
> Yes. But I'm talking about the initial page cache writes in your
> tests, and they were all into unwritten extents. These are the
> writes that had different behaviour in exach test case.
I have some difficulties grasping that. Please note that each test is a
*while loop* of the "dd" command. So, on the first test (dd with cached
writes), only the first iteration on the loop should write to an
unwritten extent; the second, third an so on should overwrite real data
(as "dd" was issued with "oflag=dsync", which immediately flushes data).
So, why you noted that "they were all into unwritten extents"? Again, I
am missing something?
> That's an application problem, not a filesystem problem. All the
> filesystem can do is align/size the data extents to match what is
> optimal for the underlying storage (as we do for RAID) and hope
> the application is smart enough to do large, well formed IOs to
> the filesystem.
You are right, I am surely approaching the issue from the wrong end...
> I think you've jumped to entirely the wrong conclusion. We do care
> about it because if you can't convey/control data alignment at the
> filesystem level, then you can't fully optimise IO at the
> application level.
Uhm no, it is my (bad) english which failed...
I fully understand XFS does a wonderful job with regard to data
alignment.
What I inteded to say is that I understand it is not an XFS problem if
an application does very small writes rather than a large one.
> The reality is that we've been doing these sorts of data alignment
> optimisations for the last 20 years with XFS and applications using
> direct IO. We care an awful lot about alignment of the filesystem
> structure to the underlying device characteristics because if we
> don't then IO performance is extremely difficult to maximise and/or
> make deterministic.
>
> However, this is such a complex domain that very, very few people
> have the knowledge and expertise to understand how to take advantage
> of it fully. It's hard even to convey just how complex it is to
> people without a solid knowledge base of filesysystem and storage
> knowledge, as this conversion shows...
True. I really thank you for the time spent on explaining the issue.
Apart that studing the source code, there are any resources I can read
about these advanced topic?
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
prev parent reply other threads:[~2018-01-04 1:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-28 23:14 Block size and read-modify-write Gionatan Danti
2018-01-02 10:25 ` Carlos Maiolino
2018-01-03 1:19 ` Dave Chinner
2018-01-03 8:19 ` Carlos Maiolino
2018-01-03 14:54 ` Gionatan Danti
2018-01-03 21:47 ` Dave Chinner
2018-01-03 22:09 ` Gionatan Danti
2018-01-03 22:59 ` Dave Chinner
2018-01-04 1:38 ` Gionatan Danti [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cbb5ecb1dac9d6c26ce9bede5424cedc@assyoma.it \
--to=g.danti@assyoma.it \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.