You just need to follow the recommendation that GEOM_PART prints out in the console. Commit or undo the changes, this will release the geom.

Ofc I understand that, but if we will hit undo then we need to undo that every time when this geom provider is detected. This could be also not very obvious for automation, should I always do undo when new geom provider is detected? I understand that in 90% this is not a big problem, and most people would commit the changes, I had already few issues with this so I would like to have some control with that, and still by default it is available.

We have integrity checking options so I'm not sure why we would go and add that.

I just show a small example how to reproduce and test, as a appliance producent I can imagine some scenario with iSCSI or with FC when this behavior would be unwanted as well.

In D9603#198497, @oshogbo wrote:

Ofc I understand that, but if we will hit undo then we need to undo that every time when this geom provider is detected. This could be also not very obvious for automation, should I always do undo when new geom provider is detected? I understand that in 90% this is not a big problem, and most people would commit the changes, I had already few issues with this so I would like to have some control with that, and still by default it is available.

No. This happens only when provider is resized. If you commit or undo the changes, the need to do this again will appear only when provider will be resized again. The provider was resized, but GEOM_PART isn't sure what it should to do, so it leaves geom in modified state and waits for user attention. If you run gpart list you can see 'modified: true' attribute. This means that some action is required with this geom.

We have integrity checking options so I'm not sure why we would go and add that.

The integrity check sysctl was introduced to keep ability to work with invalid partition tables, just because old howtos and documentation has produced a lot of broken systems, and usually it should not be used.

I just show a small example how to reproduce and test, as a appliance producent I can imagine some scenario with iSCSI or with FC when this behavior would be unwanted as well.

The main purpose why the automatic resize was introduced is adding support of such scenarios with provider resizing. Instead of adding this tunable, I prefer to disable GPT auto resizing and just mark it as CORRUPT on each resize.

It seems disabling for GPT will be not enough.
Another solution is just always apply the changes without user attention. I'm not sure it is always safe, but...

And if you still want to commit this change, you need to modify documentation :-)

I too find this feature annoying, so would like to have a sysctl to disable it.

My preference is to have auto-resize off by default, but if others want it on, i can live with it.

No. This happens only when provider is resized. If you commit or undo the changes, the need to do this again will appear only when provider will be resized again. The provider was resized, but GEOM_PART isn't sure what it should to do, so it leaves geom in modified state and waits for user attention. If you run gpart list you can see 'modified: true' attribute. This means that some action is required with this geom.

No data are sotred on disk (as far as I see) so every time this resized provider is detected the auto resize is get in action:

root@w1:~ # gpart undo zvol/test/test
GEOM: zvol/test/test: the secondary GPT header is not in the last LBA.
root@w1:~ # zpool export -F test
root@w1:~ # zpool import test
GEOM: zvol/test/test: the secondary GPT header is not in the last LBA.
GEOM_PART: zvol/test/test was automatically resized.
  Use `gpart commit zvol/test/test` to save changes or `gpart undo zvol/test/test` to revert them.

It seems disabling for GPT will be not enough.
Another solution is just always apply the changes without user attention. I'm not sure it is always safe, but...

I wouldn't want auto store such resize this coud cause a lot of problems.

In D9603#200006, @oshogbo wrote:

No. This happens only when provider is resized. If you commit or undo the changes, the need to do this again will appear only when provider will be resized again. The provider was resized, but GEOM_PART isn't sure what it should to do, so it leaves geom in modified state and waits for user attention. If you run gpart list you can see 'modified: true' attribute. This means that some action is required with this geom.

No data are sotred on disk (as far as I see) so every time this resized provider is detected the auto resize is get in action:

The resize action and probe action are two different actions.
On resize you get uncommitted changes, on probe you get corrupted partition table.

In D9603#200118, @ae wrote:

In D9603#200006, @oshogbo wrote:

No. This happens only when provider is resized. If you commit or undo the changes, the need to do this again will appear only when provider will be resized again. The provider was resized, but GEOM_PART isn't sure what it should to do, so it leaves geom in modified state and waits for user attention. If you run gpart list you can see 'modified: true' attribute. This means that some action is required with this geom.

No data are sotred on disk (as far as I see) so every time this resized provider is detected the auto resize is get in action:

The resize action and probe action are two different actions.
On resize you get uncommitted changes, on probe you get corrupted partition table.

Thank you for claryfation.
So do you accept review?