> TRIM should be treated as advisory by drives (i.e. it’s always a ‘best > effort’ type of thing), so it _shouldn’t_ cause a problem for disks that > don’t support it, though you’d probably need to try it to be sure. Worst case > you could always set up a cron job to trim the specific vdev periodically.
+1 > Even with autotrim, this is recommended (though it’s in the context of a pool > full of TRIMmable devices, I’m not sure how applicable it’d be to just a ZIL > device). This gets a bit into the details but devices can also ignore TRIM > requests that are too small for the device to do anything about. Since > autotrim generates TRIM requests for somewhat recently freed blocks, this can > sometimes generate TRIM requests like that (which get ignored). By running a > manual trim on occasion, it would allow ZFS to TRIM any ranges that might now > be large enough for the disk to trim (but at the time were freed in chunks > that were individually too small for the drive to TRIM at the time). I’ve read that ZFS autotrim is not aggressive with how often it run, optimistically to ensure larger ranges are more likely present to trim. Would the too-small ranges skipped by a previous autotrim-try be caught on the second autotrim-try, assuming they’re big enough then? My thinking is that “autotrim” is effectively identical to manually trimming (e.g., via crontab), but at the discretion of ZFS as to when. K. ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/T6ef0a71646a80e63-M347f138ee3ad630a11261ceb Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
