opnsense
Update fw_log.volt
Add additional needed live log value amounts for 30k and 80k respectively to traverse a longer time in the past. Please consider.
In the past versions there were more options to go back in time much further in opnsense. Since the new version this has been reduced, but the new interface is much faster. Can you consider these values so I dont need to manually edit the file myself after every update?
Kind regards Peter
The new interface uses a larger queue underneath, which removes the need for very large tables (which will be extremely slow to render). I don't think we should do this, knowing the search window is larger anyway.
If I'm not mistaken, the total window size is specified here:
https://github.com/opnsense/core/blob/cbd6ea95a759e61bb9a8475b877ebdabf59141e6/src/opnsense/mvc/app/views/OPNsense/Diagnostics/fw_log.volt#L874-L874
How do I display 30k records on the screen that match a specific label on the screen with the current setup? Seems to show only 100?
it shows 100 out of maximum 30k, filters can be used to limit the active set.
it shows 100 out of maximum 30k, filters can be used to limit the active set.
Yes I understand. But 100 isn't enough and before the change it was many many many more. I believe at least 20k on the old version...
Is there a problem to leave the choice up to the end user? I understand you many not use this but for those of us who do…
we'll keep it under consideration, when offering choices beyond the specification of the used components, it usually leads to complains from others at a later point in time. A bit larger is likely not an issue, but nobody has a screen that first 30k rows anyway
@pallebone https://github.com/opnsense/core/commit/07e0ba8b98a5fa8dc294e7dccf3ed1c8d089e05b should make this a little better. We can go with higher numbers, but given the constraint mentioned in the PR of this commit we should stop polling on larger table sizes to prevent rendering issues (perhaps already at > 100). The history size (total queue) should also be automatically matched and have higher values. Feel free to take a stab at this if you want in a new PR and I'll have a look. Closing this one in the meantime.
