Page MenuHomeFreeBSD

Add auto resize sysctl.
ClosedPublic

Authored by oshogbo on Feb 15 2017, 12:18 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jun 14, 5:11 AM
Unknown Object (File)
Mon, Jun 3, 4:21 PM
Unknown Object (File)
Mon, Jun 3, 4:21 PM
Unknown Object (File)
Thu, May 30, 6:42 AM
Unknown Object (File)
Mar 8 2024, 1:03 AM
Unknown Object (File)
Mar 8 2024, 12:05 AM
Unknown Object (File)
Jan 25 2024, 2:58 AM
Unknown Object (File)
Jan 25 2024, 2:58 AM
Subscribers

Details

Summary

Add sysctl which enables/disable auto resize of geom part.
In some case when we are working with zfs this can couse some troubles for example:

root@w1:~ # zfs create -V100M test/test
root@w1:~ # gpart create -s gpt /dev/zvol/test/test
root@w1:~ # zfs set volsize=200M test/test
root@w1:~ # zpool export test
cannot export 'test': pool is busy
root@w1:~ # zpool export -F test
cannot export 'test': pool is busy

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

oshogbo retitled this revision from to Add auto resize sysctl..
oshogbo updated this object.
oshogbo edited the test plan for this revision. (Show Details)
oshogbo added reviewers: trasz, ae.

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.

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.

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:

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?

sbin/geom/class/part/gpart.8
1154 โ†—(On Diff #25392)

metadata is resized

1156 โ†—(On Diff #25392)

is run to confirm the changes.

allanjude added a reviewer: allanjude.

We'll consider changing the default as a separate issue.

This revision is now accepted and ready to land.Feb 20 2017, 11:34 PM
This revision was automatically updated to reflect the committed changes.