On 8/28/23 07:23, Alexander Motin wrote:
Hi Pete,

On 27.08.2023 23:34, Pete Wright wrote:
looking at a recent pull of CURRENT i'm noticing this in the git logs:

#15079 set autotrim default to 'off' everywhere

which references this openzfs PR:
https://github.com/openzfs/zfs/pull/15079


looking at the PR i'm not seeing a reference to a bug report or anything, is anyone able to point me to a bug report for this.  it seems like a pretty major
issue:
"As it turns out having autotrim default to 'on' on FreeBSD never really worked due to mess with defines where userland and kernel module were getting different default values (userland was defaulting to 'off', module was thinking it's
'on')."

i'd just like to make sure i better understand the issue and can see if my
systems are impacted.

You are probably misinterpreting the quote.  There is nothing wrong with the autotrim itself, assuming your specific devices properly handle it. It is just saying that setting it to "on" by default on FreeBSD, that was done to keep pre-OpenZFS behavior, appeared broken for a while.  So that commit merely confirmed the status quo.  It should not affect any already existing pools.  On a new pool creation the default is now officially "off", matching OpenZFS on other platforms, but there is no reason why you can not set it to "on", if it is beneficial for your devices and workloads.  As alternative, for example, you may run trim manually from time to time during any low activity periods.



OK I think that makes sense.

So to be clear, if we were using the default autotrim=enabled behavior we in fact weren't having our SSDs trimmed? I think that's my concern, as an admin I was under the impression that it was enabled by default but apparently that wasn't actually happening.

-pete



--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

Reply via email to