Messages

Just wanted to chime in to say kudos to Franco for having the courage to overhaul dhcp6c. It's been a long-neglected part of the nix/bsd universe and was in need of some tlc. It just staggers me that this hasn't happened already at an industry level

I literally set my virtual ip as 'fd77:2ac4:81ba::/48' which seems to work for clients getting a ULA, but also causes an issue with ntp if it tries to bind. You mentioned a /64 - did you use the CIDR similar to above, or an actual address? Was the type of the virtual ip just a regular virtual ip, or other?

Sorry, didn't get the notification for this. You've probably solved it/moved on, but to answer the question, they are addresses in CIDR notation, like: fdfd:2553:8868:66::1/64. The mode is IP Alias.

RRD is disabled, netflow is disabled, don't use unbound

Less than a year in with the new disk, it's up to 133TB written (19%). This is even with things like netflow disabled. Sad.

Finally got around to looking into this. After removing all my configuration for Mullvad in OPNsense to build it again, it turns out that time on my account had expired at Mullvad's end and so all keys had been removed. Never got a notification from Mullvad. Once I paid up my account and reconfigured OPNsense, all is working again.

I noticed the same thing yesterday as well. Not sure when it started. Don't have time to troubleshoot atm but will have to investigate. Not sure whether it a change at Mullvad's end or with OPNsense.

mimgmail repo? ;)

OPNsense repo actually (os-postfix plugin). But running the update again after installing 25.1.2 bumped the Postfix version and fixed the issue (as has been previously posted).

Ok, this could coincide with

community/23.7/23.7.12:o system: change ZFS transaction group defaults to avoid excessive disk wear

We did have to apply this change because ZFS was wearing out disks with its metadata writes too much even when absolutely no data was written in the sync interval. You could say that ZFS is an always-write file system. Because if you always write the actual data written will wear the drive, not the metadata itself. ;)

In your case it has probably been wearing out the disk before this was put in place. That's at least 2 years worth of increased wear.


Cheers,
Franco

Franco, was this change applied to existing systems, not just new installations?

Because two months into my new disk, I already have 23 TB of writes ...

The interesting value for nominal/guaranteed endurance can be viewed with smartctl -a or smartctl -x. For an NVME drive it's "Percentage Used:" while for a SATA drive it's "Percentage Used Endurance Indicator".

In this particular case from one of your first posts:

Code Select Expand

Percentage Used:                    100%

So the disk is worn out according to specs and apparently in reality, too.

I monitor the wear indicators for my NAS systems in Grafana like in the attached screen shot.

Kind regards,
Patrick

Yeah, we already established that, and that's why the disk has been replaced. The last post before yours wasn't from me xD

Almost exactly 3 years. It was a conversion from a UFS install and so the disk/system is around 4 years old or so

Returning to say I've replaced the disk and it was a very smooth process. Huge kudos to Franco, Ad and Jos and all other contributors for making it so!

Appreciate the insights. Interesting regarding the level of writes, since this box has only ever been used for OPN. I thought routers/firewalls weren't that disk intensive? I don't have OPN configured to do excessive firewall logging.

Any suggestions for a replacement?

Agreed. Fortunately a reinstall with OPNsense is pretty straightforward with a configuration backup

More a matter of hoping... Lol

Oh, well, off to get a new one.

Except I also see posts like this, which suggests that the failures might not be what they seem to be.