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
