[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