skiselkov commented on this pull request.
> + */
+typedef enum {
+ SPA_FORCE_TRIM_OFF = 0, /* default */
+ SPA_FORCE_TRIM_ON
+} spa_force_trim_t;
+
+/*
+ * Should we send TRIM commands in-line during normal pool operation while
+ * deleting stuff?
+ * OFF: no
+ * ON: yes
+ */
+typedef enum {
+ SPA_AUTO_TRIM_OFF = 0, /* default */
+ SPA_AUTO_TRIM_ON
+} spa_auto_trim_t;
Drive support for TRIM is not determined pool-wide, because it is a per-device
feature and support can vary on heterogeneous pools and can even differ between
vdev opens (e.g. due to replacing a drive or changing export flags on a SAN LUN
used for ZFS backing).
*If* we ever sent a SCSI UNMAP command to a device not support it, the drive
should respond with a generic unsupported command error, which `sd(7D)` simply
forwards to ZFS, which then sets `vdev_notrim` and stops any future attempts at
TRIMming that device (until a vdev reopen clears the flag again). *However*, we
should normally never actually try to send an UNMAP command over the wire.
`sd(7D)` checks the appropriate config info tables that the device returns for
UNMAP support, so unless the device is blatantly lying about its capabilities,
if `sd(7D)` detects no UNMAP command support, it will shortcut the ioctl from
ZFS and immediately return `ENOTSUP`, which ZFS then memorizes by setting
`vdev_notrim`.
`forcetrim` is not a different TRIM mode like `autotrim`. Rather, it's a flag
controlling the behavior of ZFS ceasing to attempt sending TRIM commands if the
underlying driver returns `ENOTSUP`. With `forcetrim=on`, ZFS keeps trying to
send the TRIM commands, even if at some point the driver layer responded with
an error. This was designed in anticipation of potentially flaky RAID or SSD
firmware, which might occasionally fail a good UNMAP command for no reason. It
doesn't make `sd(7D)` send UNMAP commands if the devices indicates no support
and it doesn't modify anything about how `autotrim` or manual TRIM operate in
ZFS.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/172#discussion_r116134706
------------------------------------------
openzfs-developer
Archives: https://openzfs.topicbox-beta.com/groups/developer/
Powered by Topicbox: https://topicbox-beta.com