Re: zfs autotrim default to off now

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
pete@nomadlogic.org
@nomadlogicLA