pfsense - Raptor Engineering's fork of the main repository for pfSense

	Commit message (Collapse)	Author	Age	Files	Lines
*	RAM Disk Management - Update I - Eliminate RRD XML Dump/Restore & Alias ↵	NOYB	2017-01-08	1	-1/+2
\| \| \| \| \| \| \|	Tables Backup Age Logic Eliminate rrd dump/restore to/from xlm file. Backup and restore the entire /var/db/rrd/ to/from the RAM Disk Store. Add logic to backup alias tables if the backup is older than the table.
*	RAM Disk Management	NOYB	2017-01-08	1	-2/+6
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	1) Treat the RAM disk more like a permanent storage device with content managed/restored by the system and made available at boot up, before needed by any services. a) Handle saving and restoring RAM disk content at reboot/shutdown/boot centrally in more of a system manged fashion. b) If it's in the RAM disk store it gets restored early in the pfSense startup so it's available for whatever needs to use it. c) Services utilizing RAM disk don't need to be aware that their content is on a RAM disk, and handling content restore individually. 2) Has the benefit of eliminating some issues with the previous code as well. Such as... a) Restoring RRD multiple times during boot, potentially at least 3 times, by rc.newwanip, rc.newwanipv6, and rc.boot. Some even overlapping. b) Not removing the backups if/when not being utilized. Such as on a full install with the RAM disk option not enabled. c) Eliminate some duplicate code. 3) Looking forward. a) The more centrally system managed approach may crack the door open to making it easier to include some of the logs in the RAM disk store. As well as anything else that may be useful/desirable to retain in the RAM disk across reboots.
*	Remove all calls to conf_mount_r* functions	Renato Botelho	2016-10-12	1	-4/+0
\|
*	chmod +x on rc.backup_aliastables.sh. Ticket #6189	Chris Buechler	2016-04-18	1	-0/+0
\|
*	Alias Tables RAM Disk Store	NOYB	2016-04-17	1	-0/+24
	If ramdisk is enabled keep a copy of the alias tables to restore at boot time. Otherwise unpredictable behavior may occur due to some aliases not being available when the firewall rules load. Because alias tables are typically somewhat static, the following strategies are employed to keep write cycles to a minimum for SSD and flash drive type devices friendliness. 1) Back up during reboot/shutdown only if a backup copy of the alias table does not already exists. This is typically during the reboot when ramdisk is first enabled. 2) Update the backup copy only when the alias table is updated with a new download, typically 1 or more days, as configured in the firewall alias.