How do I find out what write continuously on my pfSense SSD

Gertjan

@bmeeks said in How do I find out what write continuously on my pfSense SSD:

I don't know why it's doing that, but that would likely account for the many disk writes (updating the records in that database and maintaining any associated indexes).

@bmeeks No coffee this morning ?
At line 6530, a SQLite database is queried (read operation) for the 'resolver' field which contains the current PID of unbound.
If it changed = restart of unbound, then that field is updated, and that's a (very small) write operation.

Normally, unbound shouldn't restart a lot ..... My unbound memory usage stats shows ones or twice a week.
That said, if this one is checked, and there are a lot of devices and/or Wifi is present, then this :

will chain gun unbound.

Btw : @slu : This (example) :

looks nice. We all love it.
To make it work, a lot of data needs to be stored and updated.
If you have just one or two small DNSBL lists, or/and your 'network' doesn't try to visit every host name that is listed in these DNSBL, then stats maintenance won't create a lot of write (update) events.
But, if you network(s) try to visit as much as blocked DNSBL as possible, then, yeah, pfBlockerer will write "a lot".

So, its all a matter of 'making choices'.

slu

@stephenw10 said in How do I find out what write continuously on my pfSense SSD:

Yes, that's pfBlocker running something.

Yes the php / pfblockerng.inc queries stop.

@stephenw10 said in How do I find out what write continuously on my pfSense SSD:

The other line looks like ZFS updates.

zfs updates still there, approximately every 5 seconds write of 40.

slu

@Gertjan said in How do I find out what write continuously on my pfSense SSD:

To make it work, a lot of data needs to be stored and updated.
If you have just one or two small DNSBL lists, or/and your 'network' doesn't try to visit every host name that is listed in these DNSBL, then stats maintenance won't create a lot of write (update) events.

Yes you are right and I underestimated that.

I tried now to disable as much as possible (complete UT1 list) but still see continuously pfblockerng.inc queries writes (no python mode).

So at the end of the day RAM disk look like the solution.

slu

I don't activate RAM disk yet (because the reboot), but don't look like there is much data in:

RAM disk 2024-08-27_11-01.png

So if this is my problem, it must write every time the same "1 MB" file.

Gertjan

You have a

@slu said in How do I find out what write continuously on my pfSense SSD:

pfSense CE system

so your SSD is accessible and replaceable ? This was one of the criteria when I picked my Netgate appliance : I could, in theory, change the drive, if needed, as I know pfSense behaves like any OS out there, and when we start adding gadgets, widgets, packages and tools, drives will get solicited.
So, a 4100 was the bare minimum for me.
Ok, it wears out after x years.
The smallest Crucial out there is .. what ... 20 box ?

IMHO : stay away from 'RAM drives'. They solve some issues, by creating other ones.

Classic iron disk don't last 'forever' neither. Some last over 10 years, some died within a couple of yours.

The problem is different but nothing really changed ;)

slu

@Gertjan said in How do I find out what write continuously on my pfSense SSD:

so your SSD is accessible and replaceable ?

Yes no problem to replace the M.2 NVMe SSD.

@Gertjan said in How do I find out what write continuously on my pfSense SSD:

Classic iron disk don't last 'forever' neither. Some last over 10 years, some died within a couple of yours.

That's true.

@Gertjan said in How do I find out what write continuously on my pfSense SSD:

IMHO : stay away from 'RAM drives'. They solve some issues, by creating other ones.

This is not clear to me, what issues can it create?
I have enough RAM (16 GB), so it will not be an issue.

On say use RAM disk, the other say not, I'm really unsure at the moment.

stephenw10

Enable it and see what happens. I usually start out at double the minimum values but since you're running some packages etc and have RAM to spare I'd start out at least 4x. So 160 + 240 MB. If somethings fail to start at boot double it again.

Gertjan

@slu said in How do I find out what write continuously on my pfSense SSD:

This is not clear to me, what issues can it create?

The ones I've never seen before ^^
Remember : I've a 4100 and I went for the MAX, but that didn't MAXed out the RAM, though.
So with a mere 4 Gbytes, still very ok to run pfSense, I can't go wild with the big resource eating packages, or use options like "pfBlockerng with all feeds selected ^^"

More serious : every non programmed power down will destroy all recent stats ...

Also : It gives a blow to the KIS concept.

stephenw10

Yup you lose the RAM disk content if power is lost. But only since the last time it wrote out.

Bob.Dig

@stephenw10 But loosing its content is what is wanted here anyways. If it would wrote everything to the disk at some point, there is nothing gained from this.

stephenw10

Writing periodically is still far fewer disk writes. And not everything is written out like that only the RRD files. The other ram disk content is only backed up at shutdown.

Gertjan

@Bob-Dig said in How do I find out what write continuously on my pfSense SSD:

there is nothing gained from this.

There is.
During shutdown, the set of files will get written out to the 'real' disk.
But de xxxxx times the files were updated are all pure bonus.

bmeeks

@Gertjan said in How do I find out what write continuously on my pfSense SSD:

@bmeeks No coffee this morning ?
At line 6530, a SQLite database is queried (read operation) for the 'resolver' field which contains the current PID of unbound.
If it changed = restart of unbound, then that field is updated, and that's a (very small) write operation.

I see both a "read" query and a "write" operation in that function loop. Notice it does a SQL SELECT and then a SQL INSERT INTO depending on what the query found. I'm not sure of all the logic as I did not author this code, so perhaps the write operation is only occasional. But it looks like all this is associated with the Dashboard Widget and is how it gathers and stores the DNS query statistics for populating the pretty graph. It follows then that the more DNS activity you have on your network the more database writes you have happening so long as the Dashboard Widget is active.

slu

@stephenw10

I enable the RAM disk and it look like better now:

iostat -d 5 6
            ada0            pass0            pass1 
 KB/t  tps  MB/s  KB/t  tps  MB/s  KB/t  tps  MB/s 
 20.9   10   0.2   0.4    0   0.0   0.0    0   0.0 
  0.0    0   0.0   0.0    0   0.0   0.0    0   0.0 
  0.0    0   0.0   0.0    0   0.0   0.0    0   0.0 
  0.0    0   0.0   0.0    0   0.0   0.0    0   0.0 
  0.0    0   0.0   0.0    0   0.0   0.0    0   0.0 
  0.0    0   0.0   0.0    0   0.0   0.0    0   0.0

As far as I understand everything is saved during normal shutdown/reboot, only power outage is an problem?
In this case pfSense should boot, but missing maybe some data (no config settings)?

slu

@bmeeks said in How do I find out what write continuously on my pfSense SSD:

It follows then that the more DNS activity you have on your network the more database writes you have happening so long as the Dashboard Widget is active.

We have much DNS activity...

stephenw10

@slu said in How do I find out what write continuously on my pfSense SSD:

but missing maybe some data (no config settings)?

I doesn't lose config. It will lose and RRD data since the last periodic write out. It loses cached stuff that will need to be re-downloaded at the next boot.

I run ram disks here on numerous machines and never see any significant issues. Even when deliberately trying!

slu

@stephenw10
this should added to the documentation (IMHO), if someone enable pfBlockerNG on a 1100
it will write "down" the storage.

Maybe an hint here:
https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html

I learned (again) many thinks of pfSense / FreeBSD.
Thanks @bmeeks @Gertjan @stephenw10

NOCling

This wasn't a big issue with UFS, but it has become a problem with the functionality of ZFS.
With a RAM disk this is no longer a problem, so it should be included in the documentation.

Keep an eye on the RAM disk values when you trigger the pfBlocker reload, then you need space for all the tables.
That's why I use 256/2048MB.

slu

RAM disk works as expected, what a huge difference!

SSD Write.png