linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:10:11 +0000 (UTC)	[thread overview]
Message-ID: <pan$9ea8b$cdf4a5be$a6b3ced0$e73fd4ce@cox.net> (raw)
In-Reply-To: 569C41B1.1090206@cn.fujitsu.com

Qu Wenruo posted on Mon, 18 Jan 2016 09:36:49 +0800 as excerpted:

>> dedup'ing data immediately when written to high-write-count data is
>> counter productive because no sooner has it been deduped then it is
>> rendered obsolete by another COW write.
> 
> And it seems that you are not familiar how kernel is caching data for
> filesystem.
> There is already kernel page cache for such case.
> No matter how many times you write, as long as you're doing buffered
> write the the data is not written to disk but cached by kernel, until
> either you triggered a manual sync or memory pressure hits threshold.

Not contradicting in general, but checking my own understanding here...

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?

Regardless, I agree, the kernel page-cache seriously mitigates the stated 
concerns.

-- 
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


  reply	other threads:[~2016-01-18  3:10 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 [this message]
2016-01-18  3:16     ` Qu Wenruo
2016-01-18  3:51       ` Duncan
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$9ea8b$cdf4a5be$a6b3ced0$e73fd4ce@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).