Re: Why is dedup inline, not delayed (as opposed to offline)? Explain like I'm five pls.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Duncan wrote on 2016/01/18 03:10 +0000:
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.

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.

Thanks for pointing out this,
Qu


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux