Andriy,
The fix looks good but I have a couple of questions:
1. Are you sure you want the TRIM priority to be lower than SCRUB?
2. You have zfs_vdev_trim_max_active set to 1 with an /* XXX */ next to
it. Does this mean you haven't settled on the final value for active max?
Thanks,
George
On
In my quest for understanding why my TXG size is so small, I found the
following code in ZFS on Linux. In IllumOS, the code is formatted
differently but it's basically the same:
uint64_t
spa_get_asize(spa_t *spa, uint64_t lsize)
{
/*
* The worst case is single-sector max-parity RAID-Z blocks, in
Seems to me a trim should have higher priority than scrub. One rationale
for this is that a trim can free up underlying storage, allowing the device
to take some actions that can actually make subsequent I/Os (write I/Os at
any rate) go faster. If the scrub is going to cause any write activity,
On Sat, Nov 30, 2013 at 10:13 AM, Andriy Gapon a...@freebsd.org wrote:
[resending with CC fixed]
Matt,
as you most likely know, ZFS/FreeBSD already has ability to use TRIM command
with disks that support it.
As the command can be quite slow and it is a maintenance kind of command, it
makes
