ZFS Non-boot pool history filling with "import" at reboot

[ers]

Hi,
in older version of FreeBSD zfs pools were visible after reboot and in their history was not filled with repeated "import" items.
After a break i get back to FreeBSD 14.0R/14.1R and i see that on every reboot non boot pools have new "import" item.
Is there a way to have additional non-boot pools which history does not get filled with those "imports" like in older FreeBSD versions?

 

[T-Daemon]

in older version of FreeBSD zfs pools were visible after reboot and in their history was not filled with repeated "import" items.

Which older version of FreeBSD? 7.0 - 12.4 OpenSolaris ZFS or OpenZFS 14.0 >=13.0?

Is there a way to have additional non-boot pools which history does not get filled with those "imports" like in older FreeBSD versions?

Currently there is no option to manipulate zpool history in OpenZFS. Every event is recorded in the history log.



By the way, the history log is implemented as a ring (circular) buffer, excluding zpool creation log, with a maximum and a minimum file size of:

109          * Figure out maximum size of history log.  We set it at
110          * 0.1% of pool size, with a max of 1G and min of 128KB.

. https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/module/zfs/spa_history.c

At one point older history logs get overwritten. If zpool history is important, one should consider to save those logs by a cron job from time to time. The zpool history can accumulate a lot if an automatic snapshot utility with short term cron scheduling is in use for example.

There was a discussion on Github to exclude specific logs, however I can't say whether it is still being tracked or not.

zpool history is limited to ~1MB of text #13126

Make zpool events and zpool history useful even when using snapshots #13374

Create a --no-log feature to allow elimination of certain logging events. #13376



See also other SPA (Storage Pool Allocator) files under sys/contrib/openzfs/module/zfs. Quite informative.

spa.c
spa_checkpoint.c
spa_config.c
spa_errlog.c
spa_history.c
spa_log_spacemap.c
spa_misc.c
spa_stats.c

 

[ers]

I do not want to manipulate pool log.
"Older" i ment for example 10.0R, where after reboot in history is no "import" added after each reboot on pool hisotry.
I would like to avoid those logs about "importing" the pool. This has no value, makes unnecessary writes and obfuscate important logs.
And yes, this is possible, because boot pool have no such log as "import" on boot (in 14.1R).

 

[T-Daemon]

I would like to avoid those logs about "importing" the pool. ...
And yes, this is possible, because boot pool have no such log as "import" on boot (in 14.1R).

The lack of “import” logs from a booted root pool does not mean that other imported pools from the running system can avoid the “import” logs.

Booting a root pool is something different than importing a pool from a running system.

Obviously the FreeBSD loader (BIOS: gptzfsboot(8), UEFI: loader.efi(8)) are able to access the ZFS without importing the pool (escape at the boot menu to loader prompt, execute ls).

A review of the source code of the loader mentioned above suggests that there is no pool import either, the loaders can access the ZFS and remains accessible throughout the booting process. When there is no pool import, then no "import" log is recorded in the pool history.

As already mentioned, there is currently no way to avoid the logging of pool import events unless the system is booted from this pool. All other import events of a pool from a running system are logged in any case.

... logs about "importing" the pool. This has no value, makes unnecessary writes and obfuscate important logs.

You could pipe zpool history to grep(1) and filter patterns out, i.e.: zpool history | grep -v import

 

[ers]

So, how this was possible in 10.0R and in 14.1R is not?
If this is only on code level so then it will be possible to avoid it.
However, I am looking for solution without messing in code.

You could pipe zpool history to grep(1) and filter patterns out, i.e.: zpool history | grep -v import

: ) : D Please, be more constructive and creative. RTFM-like answer is has no value. Maybe i do not know everything (like MacGyver, the real one from 1985) but i know this one... : ) : D
I do not want to filter it out. I want to decrease unnecessary writes to flash storage.

 

[Mirror176]

I do not want to manipulate pool log.
"Older" i ment for example 10.0R, where after reboot in history is no "import" added after each reboot on pool hisotry.
I would like to avoid those logs about "importing" the pool. This has no value, makes unnecessary writes and obfuscate important logs.
And yes, this is possible, because boot pool have no such log as "import" on boot (in 14.1R).

I thought FreeBSD moving from the older ported Sun code that was Illumos maintained/directed to OpenZFS based on ZFS on Linux codebase lead to changes involving zpool.cache. I "think" it moved from /boot/zfs to /etc/zfs but I'm not sure; best to look it up. Maybe something strange is happening from having two copies around or something messed up with a copy? There is a pool property 'cachefile' that says where the cache is found if for some reason you wanted to move it. At this point have you also tried an export+import (maybe forced import)? Is there anything else weird to note about pool statuses?

For general log bloat, I thought I heard of others having concern of some history activity bloat and filtering becoming a goal but haven't heard of progress on that front.

 

[Andriy]

I think that the difference is explained by the switch to OpenZFS code.
Older FreeBSD ZFS code handled zpool.cache entirely in kernel.
Pools listed in the cache were imported silently.
With OpenZFS code, the imports are done by the zpool rc script using zpool import command, so they are no longer silent.

 

[T-Daemon]

However, I am looking for solution without messing in code.

There is none with the current OpenZFS version.

: ) : D

I like the stringing together of emojis. Thumbs up. I am glade I could make you hilariously laugh to my efforts to present a solution to clear up the history output, sorry to hear that it was uncreative, unconstructive and of no value.

Please, be more constructive and creative.

I'll try.

How about: RTF source code to find out "how this was possible in 10.0R and in 14.1R is not". Better?

Now seriously,

I do not want to filter it out. I want to decrease unnecessary writes to flash storage.

If you want that, you have to mess with the code.

Alternatively, open a PR and ask for an --no-log option. Perhaps the FreeBSD developers are considering such an option to introduce a patched version of OpenZFS zpool(8) into the base.

Or open an issue (maybe join the existing ones from comment #2) upstream and ask the OpenZFS maintainers for a "import --no-log" flag. It seems there is a consideration of a no-log feature.

 

[ers]

I thought FreeBSD moving from the older ported Sun code that was Illumos maintained/directed to OpenZFS based on ZFS on Linux codebase lead to changes involving zpool.cache. I "think" it moved from /boot/zfs to /etc/zfs but I'm not sure; best to look it up. Maybe something strange is happening from having two copies around or something messed up with a copy? There is a pool property 'cachefile' that says where the cache is found if for some reason you wanted to move it. At this point have you also tried an export+import (maybe forced import)? Is there anything else weird to note about pool statuses?

For general log bloat, I thought I heard of others having concern of some history activity bloat and filtering becoming a goal but haven't heard of progress on that front.

I was trying change the cachefile property and point to file in use. It looks like there is no cachefile used or I did something wrong.
The boot pool cachefile property leads to nonexistent path.
Do you know how to properly check it?

Export+import by hand makes another log entry. Nothing changed. The same for forced one.

Pool status is simple. Create on fresh sdd. Set few properties like atime=off and compression=lz4.
Then a large herd of import entries......

 

[ers]

There is none with the current OpenZFS version.

Did you read Andiry reply? There is a tiny chance...

I appreciate your effort! However i prefer when errors are corrected not masked. Sorry, filtered.
If i want trivial filtering there would be no question to forum.

--no-log option resolves this problem. But will they even listen? Maybe if my name were famous in BSD world... like f.e. Thompson, Ritchie, Kernighan or McIlroy, but it is not...

 

[ers]

With OpenZFS code, the imports are done by the zpool rc script using zpool import command, so they are no longer silent.

Great! Is there a chance to modify it to stop this behavior?

 

[T-Daemon]

Did you read Andiry reply? There is a tiny chance...

Yes I did read that reply, and the answer is: there's no chance. The rc script he is referring to is /etc/rc.d/zpool.

You may recognize the pool "import" log originates from that script:

                       zpool import -c $cachefile -a -N

 % zpool history <pool>
2024-08-27.11:00:31 zpool import -c /etc/zfs/zpool.cache -a -N

No modification of the "zpool" script can selectively disable import logging, or any pool history logging.

What you want must be done on code level, by introducing a no-log function to import events. No offense, but it's obvious that you have no knowledge of how pool logging is handled.

I'm not an expert, yet I can say with certainty that there is currently no possibility to avoid pool logging by setting an option.

I appreciate your effort!

Then you have a funny way to show it. I certainly don't laugh at people who want to help me and insult them.

--no-log option resolves this problem. But will they even listen? Maybe if my name were famous in BSD world... like f.e. Thompson, Ritchie, Kernighan or McIlroy, but it is not...

What makes you think that none of the developers will listen to your proposal? Developers don't look who you are, they look if the proposal is rational and feasible. On the other hand, the “import” event of the pool may be considered too important to be excluded.

But you will never know if you don't report such a demand.