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

Reply via email to