From: Phillip Susi <psusi@ubuntu.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Matthew Wilcox <willy@linux.intel.com>,
"Zuckerman, Boris" <borisz@hp.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Tracking actual disk write sources instead of flush thread
Date: Wed, 23 Apr 2014 21:39:07 -0400 [thread overview]
Message-ID: <53586B3B.7000406@ubuntu.com> (raw)
In-Reply-To: <68A83B3D-D029-4863-B9D9-2BD9894FDFDC@dilger.ca>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04/23/2014 07:19 PM, Andreas Dilger wrote:
> I think that adding a pointer or integer per page would meet
> resistance, but I think it is pretty reasonable to track this on a
> per-inode basis. It is fairly uncommon to have multiple threads
> writing to the same file, and I would guess it is vanishingly rare
> that different applications are writing to the same file at one
> time.
Wherever the current counter is should be fine, the question is when
it gets updated. Rather than updating it on sync it just needs
updated on actual write() / page dirty.
> Storing {current->comm}.{pid} would take 20 bytes of space per
> inode, but would be much more useful than just storing {pid}, since
> a process may be long gone by the time that the blocks are even
> submitted to disk due to delayed allocation and such.
>
> It would be possible to store a refcounted struct with this info
> pointed to from the inode, since it would only be useful on inodes
> being written, but that has to be balanced against the complexity
> of maintaining that struct and the potential of saving 12 bytes per
> inode (since there would still need to be a pointer in the inode).
That might be a bit overkill. I believe the current interface just
has a counter of bytes of IO hung off the task, so you can't catch
very short lived processes. That's probably not too bad. I don't
think it needs tracked on a per inode basis; just being able to sort
out that this process is doing the writing instead of some other
random process or the flush task that actually ends up submitting the bio.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJTWGs7AAoJEI5FoCIzSKrwbiUH/iCQYRn74zTt/G1pSVEKiNCj
+j0AL004tkU8UHZkgUvTedYzMyaqy5gs59IahwuPX+u/U6jRIUElrkBpecL5E+q/
OgfL+g/HybC0YbMJDKWedjRshxwHyjLLhRuPxTPSLXLxOPj8ZCvhzg2Hc2UkswJ5
/mIiWlKt70Ezxf2sq4Xnna8nGk6iuTlNqCc/VkB/AOu+aSsYcdIkoi1T/O+vUMHz
uRUwVuo+grn85NdRjpL0l7sXT1FJaJsbQkjy72akiBEDWN4J/3w48ZaoHr1Gv7tB
uCgWmZgPdQYeftkK0gnU7MSbWplcr7VrwdnYr9BdzEluKaX6I0vxejbpPYcAwOo=
=p1rv
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-04-24 1:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 2:01 Tracking actual disk write sources instead of flush thread Phillip Susi
2014-04-16 14:01 ` Matthew Wilcox
2014-04-16 15:15 ` Phillip Susi
2014-04-16 16:42 ` Andreas Dilger
2014-04-16 17:44 ` Zuckerman, Boris
2014-04-16 18:18 ` Phillip Susi
2014-04-16 18:28 ` Zuckerman, Boris
2014-04-16 19:27 ` Phillip Susi
2014-04-23 13:48 ` Matthew Wilcox
2014-04-23 19:39 ` Phillip Susi
2014-04-23 23:00 ` Theodore Ts'o
2014-04-24 1:20 ` Phillip Susi
2014-04-23 23:19 ` Andreas Dilger
2014-04-24 1:39 ` Phillip Susi [this message]
2014-04-28 3:27 ` Andi Kleen
2014-04-16 19:33 ` Andi Kleen
2014-04-24 19:33 ` Jan Kara
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=53586B3B.7000406@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=adilger@dilger.ca \
--cc=borisz@hp.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=willy@linux.intel.com \
/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.