This is the kind of change that seems simple and obvious, but opens up semantic gray areas in the language and the runtime. Is the intent that 0 means that trim is disabled? Should this coordinate with other tunable? How would one express unlimited? I guess as 0x7ffffffffffffff since it's a signed quad? It's now possible to feed a negative value into d_delmaxsize where that wasn't possible before (even though the field is signed), so does the rest of the system know how to deal with that?

This revision now requires changes to proceed.Jul 11 2021, 7:57 PM

In D19169#700919, @scottl wrote:

This is the kind of change that seems simple and obvious, but opens up semantic gray areas in the language and the runtime. Is the intent that 0 means that trim is disabled? Should this coordinate with other tunable? How would one express unlimited? I guess as 0x7ffffffffffffff since it's a signed quad? It's now possible to feed a negative value into d_delmaxsize where that wasn't possible before (even though the field is signed), so does the rest of the system know how to deal with that?

Fair point. I made this a int64 because off_t is int64_t. However, it doesn't make sense to have it be negative. It's a pilot error that would likely take down the whole system (or result in a weird limit). Setting it to '0' would also have bad effects because that would likely result in an infinite loop in geom. The intent isn't to disable all trim with setting it to '0', so nothing to enable that is present. A legal 'minimum' has to be params.secsize. I'll rework.

I'm no longer working on this.