Ok initial version can be found here:-
http://blog.multiplay.co.uk/dropzone/freebsd/zz-zfs-trim-priority.patch
The key differences from Andriy's original:
1. Switches zio_trim to use ZIO_TYPE_FREE with the new ZIO_FREE_PHYS_PIPELINE
so that minimal changes are required to allow compatibility
I've just been doing some testing on this as I suspected that the current
default of vfs.zfs.vdev.trim_max_active=1 could prevent trim coallessing
at the lower levels but it seems that the number of requests submitted to
the vdev / device can exceed the trim_max_active value.
For example I've
That looks fine. I don't have any experience with how devices respond to
concurrent TRIM commands, so I would defer to you on what that
trim_max_active should be.
I could see arguments either way on whether TRIM should be higher or lower
priority than SCRUB, but in practice it doesn't matter;
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
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
