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; the priority only comes into play once you have zfs_vdev_max_active total i/os queued to the device. By default this is larger than the sum of all queue's max_active's, so unless zfs_vdev_max_active is lowered it is not possible for the priority to matter. --matt On Sat, Nov 30, 2013 at 7:13 AM, Andriy Gapon <[email protected]> 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 sense to assign a very low priority to it. > > I've come up with the following change that introduces a new priority for > the > TRIM zios: > http://people.freebsd.org/~avg/zfs-trim-priority.diff > To be honest, this change actually attempts to restore what we already had > in > FreeBSD before I merged your write throttle & i/o scheduler performance > work. > > Could you please review the change? > I am not sure if I correctly translated my intent to the min_active and > max_active values. I will greatly appreciate your help with these. > > Thank you! > -- > Andriy Gapon >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
