Yes. Set the filter up correctly next time!Frosty wrote:Is there any way to get around this?
Whew, I was worried that this was just how ZoneMinder handled purging. Here's a screenshot of my filter configuration (note that the percentage is only set to 8 because this is a small-scale test; in regular circulation, it would obviously be set much higher):mikb wrote:Yes. Set the filter up correctly next time!Frosty wrote:Is there any way to get around this?
Sometimes it's better to submit the filter and see what it does before allowing it to execute. That way you find out what it's about to do before it does nothing/too much.
Do you still have the filter settings you used? If so, post them here and someone will probably spot the deliberate mistake ...
That's the thing - ZoneMinder recordings are the only things on there. This machine was a clean install of Ubuntu Server and disk usage was only at 2% when I started recording. In fact, it took quite a while to fill it up to 8% because I had the framerates set very low (Mocord; 1FPS idle, 5FPS motion).mikb wrote:OK that looks good, but maybe you are not on the same page as ZoneMinder regarding "used" and "free"
If you are trying to tell ZoneMinder to only use up to 8% of the disk -- then that would seem sensible for testing. But ... big but ... only if Zoneminder events are the ONLY THING on that disk device.
How much space /usage is there on the disk where your events (jpgs) are being stored?
If you have a disk with 90% of other stuff (let's say your OS and all your apps!) -- that rule will fire, and fire, and fire until there's nothing of ZM's events left. I suspect that might be what happened.
It's "delete on > 8% of the total disk space in-use, as reported by the OS", so what does "df -h /mnt/point/for/your/images" say? If it's anything over 8% used, that's why it went rampant.
Either: Set 95% from now on and don't worry about testing, or give ZoneMinder a dedicated disk/mounted file system for its events, which will be 0% full at the start, and slowly climb -- and if it does overflow by some quirk, it will only bring down ZoneMinder, not your OS/other apps.
Simple, but not optimal setup.Yes. If this were put into a production environment, I'd probably set it up with the OS on a smaller disk and the DVR data on a separate disk (or RAID array) or partition it with the OS on a small volume and the DVR data on a separate, larger volume. We'll get there when we get there though - first I need to make sure I can get everything to work properly on this test rig before we dive into those more advanced setups.mikb wrote:In which case you've got me stumped!
If there is only one file system, with everything in it (All of your OS, files, and zoneminder's events) and it's only 8% full, then you have one (1) HUGE file system
Yup. This is what I've got:mikb wrote: Or you have more than one file system, with an (unspecified) % full OS section, any others, and finally a file system (disk, partition, volume) that is mostly empty just for Zoneminder, ranging 2-8% that got emptied totally when there was no need. Which shouldn't happen[tm].
Can you post the full output of "df -h" to see how simple->complex your file systems actually are?
Code: Select all
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ZoneMinderTest--vg-root 228G 2.9G 214G 2% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 973M 4.0K 973M 1% /dev
tmpfs 197M 584K 197M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 984M 0 984M 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda1 236M 66M 158M 30% /bootI don't know for sure. I know that "PurgeWhenFull" is the only filter on the dropdown menu in the filters dialog box though.Another thought: Is there another rule running, something about "Purge When Old" that may have caught you out?
I'm not sure how you work out exactly which rule did the deleting, as all I can notice in my logs is it saying "Deleting event 123456" -- but not *why*.