From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Why is dedup inline, not delayed (as opposed to offline)? Explain like I'm five pls.
Date: Mon, 18 Jan 2016 03:51:54 +0000 (UTC) [thread overview]
Message-ID: <pan$9dd9b$58cdc4a$94401f0f$f97ce29e@cox.net> (raw)
In-Reply-To: 569C58FB.70407@cn.fujitsu.com
Qu Wenruo posted on Mon, 18 Jan 2016 11:16:11 +0800 as excerpted:
> Duncan wrote on 2016/01/18 03:10 +0000:
>>
>> Doesn't the kernel write cache get synced by timeout as well as
>> memory pressure and manual sync, with the timeouts found in
>> /proc/sys/vm/dirty_*_centisecs, with defaults of 5 seconds
>> background and 30 seconds higher priority foreground expiry?
>>
> Yep, I forgot timeout. It can also be specified by per fs mount
> option "commit=".
>
> But I never /proc/sys/vm/dirty_* interface before... I'd better
> check the code or add some debug pr_info to learn such behavior.
Checking a bit more my understanding, since you brought up the
btrfs "commit=" mount option.
I knew about the option previously, and obviously knew it worked in the
same context as the page-cache stuff, but in my understanding the btrfs
"commit=" mount option operates at the filesystem layer, not the general
filesystem-vm layer controlled by /proc/sys/vm/dirty_*. In my
understanding, therefore, the two timeouts could effectively be added,
yielding a maximum 1 minute (30 seconds btrfs default commit time plus 30
seconds vm expiry) commit time.
But that has always been an unverified on my part fuzzy assumption. The
two times could be the same layer, with the btrfs mount option being a
per-filesystem method of controlling the same thing that /proc/sys/vm/
dirty_expire_centisecs controls globally (as you seemed to imply above),
or the two could be different layers but with the countdown times
overlapping, both of which would result in a 30-second total timeout,
instead of the 30+30=60 that I had assumed.
And while we're at it, how does /proc/sys/vm/vfs_cache_pressure play into
all this? I know the dirty_* and how the dirty_*bytes vs. dirty_*ratio
vs. dirty_*centisecs thing works, but don't quite understand how
vfs_cache_pressure fits in with dirty_*.
Of course if there's already a good writeup on the dirty_* vs
vfs_cache_pressure question somewhere, a link would be fine. But I doubt
there's good info on how the btrfs commit= mount option fits into it all,
as the btrfs option is relatively newer and it's likely I'd have seen
that all ready, if it was out there.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-01-18 3:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-16 12:27 Why is dedup inline, not delayed (as opposed to offline)? Explain like I'm five pls Al
2016-01-16 14:10 ` Duncan
2016-01-16 18:07 ` Rich Freeman
2016-01-18 12:23 ` Austin S. Hemmelgarn
2016-01-23 22:22 ` Mark Fasheh
2016-01-20 14:49 ` Al
2016-01-20 14:43 ` Al
2016-01-21 8:23 ` Qu Wenruo
2016-01-21 14:53 ` Al
2016-01-21 17:23 ` Chris Murphy
2016-01-22 11:33 ` Al
2016-01-23 2:44 ` Chris Murphy
2016-02-02 2:55 ` Qu Wenruo
2016-01-18 1:36 ` Qu Wenruo
2016-01-18 3:10 ` Duncan
2016-01-18 3:16 ` Qu Wenruo
2016-01-18 3:51 ` Duncan [this message]
2016-01-18 12:48 ` Austin S. Hemmelgarn
2016-01-19 8:30 ` Duncan
2016-01-19 9:14 ` Duncan
2016-01-19 12:28 ` Austin S. Hemmelgarn
2016-01-19 15:40 ` Duncan
2016-01-20 8:32 ` Brendan Hide
2016-01-19 12:21 ` Austin S. Hemmelgarn
2016-01-20 15:12 ` Al
2016-01-20 18:21 ` Duncan
2016-01-20 14:53 ` Al
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='pan$9dd9b$58cdc4a$94401f0f$f97ce29e@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).