06-20-2016 06:17 AM
Thanks for the tag. So I think/thought there are space-saving mechanisms in place now. Let me check and circle back.
06-20-2016 05:58 PM
... which given the tendency of all flash-type memories to not enjoy repeated high frequency write cycles probably ought not to be one that keeps hammering the same section of the storage. A delete LRU-on-full-disk strategy might help level the wear without too much engineering work. particularly if we assume someone puts in daily/hourly/whatever logfile rotation. However, I think it's mainly the database that fills up the disk, so that data is pretty easy to "age out" - but levelling the disk wear might not be.
Yup. Flash is not the panacea or drop in replacement for all situations. I was really glad to see this:
A tiny 300GB hard drive would be perfect for an appliance like the cloud key that will have lots of writing but that the performance isn't super critical.
Having wifi problems? Take a look here first: https://help.ubnt.com/hc/en-us/articles/221029967-UniFi-Debugging-Intermittent-Connectivity-Issues-on-your-UAP
11-11-2017 10:30 PM
I tried these instructions and for a month everything was fine. The next time Unifi released a firmware update, I applied it, and the resulting update bricked my Cloud Key. I recommend no one perform these steps.
11-11-2017 11:14 PM
What gives? I posted a topic about my cloud key now being bricked following an update and it was deleted within an hour? What kind of moderators delete requests for help???
01-13-2018 03:33 PM - edited 01-13-2018 03:36 PM
If it helps, I can see your posts...and feel your pain
I had the disk full problem on my 1.5GB CK, and while support was willing to tell me about the bigger CKs (8GB) available, we did finally find a workaround, but it's not as elegant as I had hoped.
The Problem - if your CK fills up (even on 5.6.29), you can't do anything - no backups, no compacting, and I wasn't feeling too comfortable mucking about via SSH and rm some files. (But if someone knows a good directory to purge and perhaps solve this problem, please chime in! - that would be a much better solution until this can be fixed from the controller software or web UI)
I also didn't want to have to worry about my SD card failing or corrupting the database, so the whole moving the mongo db over to the SD card, while cool, was not really what I was looking for.
The "solution" - Reset, reboot, restore from a backup.
If you are bricked, hopefully using the emergency UI will get you back to where you can reset (try the unifi controller software, or get techy with "arp -a" to find the CK and log in via the web interface, or maybe SSH)
Yes you lose some data (since your last backup), and yes, it doesn't really solve the problem, but it did get us up and running again (85% free disk space!) with minimal interruption and data loss.
Hope this helps someone...