zfs set spamming

[zombiehoffa]

I'm on omv 4.1.31-1. I installed proxmox kernel and zfs, created a zpool manually (for more control over how the raidz2 was created) and it showed up in the openzfs plugin in omv so I haven't touched anything in the plugin itself other than to note that my zpool was there (and the underlying datasets) and have been using it with a few bumps (bad cable causing udma cmc error that is now fixed). When I look at zpool history there's constant spamming in there with zfs set commands, I assume from the plugin and I'm curious how to get this to stop.

Here's some examples: 2020-01-12.09:09:06 zfs set omvzfsplugin:uuid=8fd025c3-c908-4b89-b37f-acae0444081a zdata 2020-01-12.09:09:10 zfs set omvzfsplugin:uuid=068d155c-3d32-4992-9c5d-57567b1b6a48 zdata/archive 2020-01-12.09:09:15 zfs set omvzfsplugin:uuid=467afe74-5169-4eea-90c3-6ca0bf9f5392 zdata/backupdockerconf 2020-01-12.09:09:19 zfs set omvzfsplugin:uuid=8eb92b9a-9a28-453f-aff0-e14a0c9a724e zdata/dockerconf 2020-01-12.09:09:23 zfs set omvzfsplugin:uuid=980d894d-4bc1-44ae-b04d-ba8d2db43ebf zdata/dockerpath 2020-01-12.09:09:27 zfs set omvzfsplugin:uuid=fcda2be3-a3fa-415a-9ddb-37c94865c315 zdata/downloads 2020-01-12.09:09:31 zfs set omvzfsplugin:uuid=26275790-9085-457a-a971-77995f59291a zdata/incomplete 2020-01-12.09:09:35 zfs set omvzfsplugin:uuid=1e9c735e-9520-4fe7-bcde-f3074e2b939b zdata/mayan 2020-01-12.09:09:40 zfs set omvzfsplugin:uuid=cda757e9-0dd6-4500-b05e-2e90f061309d zdata/mayanbackup 2020-01-12.09:09:44 zfs set omvzfsplugin:uuid=4d1dc217-0e99-4170-a937-86939c954f07 zdata/mayanwatch 2020-01-12.09:09:48 zfs set omvzfsplugin:uuid=1c5d2959-dcfe-470e-807a-c7c36f9c4914 zdata/omvbackup 2020-01-12.09:09:52 zfs set omvzfsplugin:uuid=48d8e290-4eaa-47a2-a8e5-57913fa73982 zdata/test 2020-01-12.09:09:57 zfs set omvzfsplugin:uuid=0bba8625-6b20-441a-b029-951f5731e5ac zdata/urbackup 2020-01-12.09:10:21 zfs set omvzfsplugin:uuid=8fd025c3-c908-4b89-b37f-acae0444081a zdata 2020-01-12.09:10:25 zfs set omvzfsplugin:uuid=068d155c-3d32-4992-9c5d-57567b1b6a48 zdata/archive 2020-01-12.09:10:30 zfs set omvzfsplugin:uuid=467afe74-5169-4eea-90c3-6ca0bf9f5392 zdata/backupdockerconf 2020-01-12.09:10:34 zfs set omvzfsplugin:uuid=8eb92b9a-9a28-453f-aff0-e14a0c9a724e zdata/dockerconf 2020-01-12.09:10:38 zfs set omvzfsplugin:uuid=980d894d-4bc1-44ae-b04d-ba8d2db43ebf zdata/dockerpath 2020-01-12.09:10:42 zfs set omvzfsplugin:uuid=fcda2be3-a3fa-415a-9ddb-37c94865c315 zdata/downloads 2020-01-12.09:10:47 zfs set omvzfsplugin:uuid=26275790-9085-457a-a971-77995f59291a zdata/incomplete 2020-01-12.09:10:51 zfs set omvzfsplugin:uuid=1e9c735e-9520-4fe7-bcde-f3074e2b939b zdata/mayan 2020-01-12.09:10:55 zfs set omvzfsplugin:uuid=cda757e9-0dd6-4500-b05e-2e90f061309d zdata/mayanbackup 2020-01-12.09:10:59 zfs set omvzfsplugin:uuid=4d1dc217-0e99-4170-a937-86939c954f07 zdata/mayanwatch 2020-01-12.09:11:03 zfs set omvzfsplugin:uuid=1c5d2959-dcfe-470e-807a-c7c36f9c4914 zdata/omvbackup 2020-01-12.09:11:08 zfs set omvzfsplugin:uuid=48d8e290-4eaa-47a2-a8e5-57913fa73982 zdata/test 2020-01-12.09:11:12 zfs set omvzfsplugin:uuid=0bba8625-6b20-441a-b029-951f5731e5ac zdata/urbackup

[ryecoaaron]

Regardless of whether you use the zfs tab, the plugin is going to be used in the filesystems tab and shared folders and other places because the plugin supplies the zfs backend. The backend is what lets OMV use zfs filesystems

[zombiehoffa]

I understand that, what I don't understand is why when I look at zpool history something (I assume the plugin) is running "zfs set omvzfsplugin:uuid=SOMEUID zpool/dataset" once every 10 minutes or so for 25 or so times since I created the datasets 3 days ago now. It hasn't done it in the last 4 hours so maybe whatever is going on has sorted itself out? I would have expected that to be needed to be run once per created dataset to apply the label needed to integrate with the rest of OMV, not multiple times.

[ryecoaaron]

There is nothing in the plugin that runs a regular schedule that I can think. I remember when the code was added to mark the pool with an identifier but I didn’t write it. Is this causing a problem other than annoying log?

[zombiehoffa]

mostly just an annoying log afaik. I am not familiar enough with zpool history to know if it's going to cause a problem if it does it enough. One thing though, it's not really a regular check, it's actually setting the identifier multiple times, not necessarily checking that the identifier is set (I have no way of knowing afaik if it's checking first and then setting because the checking is wrong or if something else is going on).

[ryecoaaron]

I get that. I didn’t say it was check. I was just saying it isn’t something the plugin schedules. Maybe it keeps trying to set the uuid until it is successful. I will look at the code when I’m not doing something much more important (beer :) ).

[zombiehoffa]

Thanks, I appreciate it. One other thing for when you're done with beer, it kicked off a scrub last night. There's no indication in the history as to why and it's not scheduled in crontab on omv (or in root crontab from the terminal, I checked). I'm not sure if that could be related or if there is some other place I didn't think to look that the plugin would schedule a scrub and it's just a coincidence?

[ryecoaaron]

The scrub is something setup by the zfs package not omv or the plugin. Probably a systemd timer.

[subzero79]

That should only happen when using the webui, in the fs section or the zfs section i can't remember. Does this happens even when the webui is not open? I ask because this was added to the php backend only and this runs on demand by the webui.

[zombiehoffa]

I couldn't actually tell you because it stopped doing it and the ui was open although not necessarily as the visible tab and not necessarily on the fs or zfs section during the times I did get those zfs commands showing up, I just don't remember. I've had the ui open now to those two pages and it didn't cause a zfs set command.