[DragonFlyBSD - Bug #2759] (Feedback) hammer(8) doesn't respect the timelimit for deduplication

bugtracker-admin at leaf.dragonflybsd.org bugtracker-admin at leaf.dragonflybsd.org
Wed Jan 7 16:15:07 PST 2015


Issue #2759 has been updated by tuxillo.

File cmd_dedup01.diff added
Category set to Userland
Status changed from New to Feedback
Assignee set to tuxillo
Priority changed from Normal to High
Target version set to 4.2.x

Hi,

Please try the patch attached (in non Prod systems) and see if it works correctly.

Cheers,
Antonio Huete

----------------------------------------
Bug #2759: hammer(8) doesn't respect the timelimit for deduplication
http://bugs.dragonflybsd.org/issues/2759#change-12395

* Author: ftigeot
* Status: Feedback
* Priority: High
* Assignee: tuxillo
* Category: Userland
* Target version: 4.2.x
----------------------------------------
Environment:
- a storage server with a 20TB /data volume
- a dataset potentially deduplication-friendly (protein sequences)
- deduplication has been enabled with a 5mn per day timelimit for /data

Problem:
- hammer(8) is running most of the day, inducing a high background I/O load on the disks
- the particular command is "hammer -t 300 dedup"

That command is run from the nightly hammer cleanup cron. It starts at 3am an never finishes.

A quick test on a brand new hammer volume confirms the -t argument to hammer dedup has no effect.
hammer dedup will run forever as long as there is still data to deduplicate.


---Files--------------------------------
cmd_dedup01.diff (3.86 KB)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



More information about the Bugs mailing list