Your stats.db and querylog.json files will always be in your working directory which you can find by ps |grep -i adguardhome. The -w signifies the working directory. This is normally set by your startup script which you can find by find / -name S*uard*. It’ll likely be in the /etc/rc.d directory. For v4 beta 1 on MT1300 the default was /tmp for the working directory.
Did you cut anything off the response? I’ve not seen adguard started without a working directory specified. Obviously, your working directory is /etc/AdGuardHome though
What is the output of your cat /etc/config/adguardhome? This is what the startup script references.
Hi wcs2228:
There are two reasons to consider:
1, It takes up flash storage space;
2, Frequent reads and writes reduce the flash life;
So the new firmware set it to ‘false’.
Does that mean GL-MT2500 has less flash storage space than GL-MV1000W and reads/writes affect the newer router more?
My GL-MT2500 has a “/” root size of 7.19 GB (6.76 GB free) flash and my GL-MV1000W has a “/” root size of 489 MB (317 MB free) flash. In terms of flash wear, when you use things, they eventually wear out and you just have to buy a new one, so you should let the owner decide through a UI because the setting is not available in the AdGuard Home UI.
Nothing has been cut off.
Your GL-MT1300 is different from my GL-MT2500. In any case, I am satisfied with the log files being in /etc/AdguardHome/data.
Hi wsc2228:
There is another concern:the storage space will lead to the system running and upgrade issue.
We will consider adding a local switch to save AdguardHome information.
Thank you!
My GL-MT2500 is a dedicated AdGuard Home server, with only LAN coonected and no routing, DHCP, VPN, etc. and unnecessary startup services disabled,
6.76 GB of storage is not enough?
Hi wcs2228：
I’m sorry I wasn’t clear.
I said above not just for MT2500.
If large amounts of data are saved locally, some configurations could be lost when the firmware is updated.
Thanks!
That is why I suggested to let the owner decide the setting through a UI, depending on the router model and personal preferences.
I do not understand how AdGuard Home log files would affect configurations. If so, then offer to delete the log files when updating the firmware.
In summary, I believe there are various ways that GL.iNet can offer to keep longer logs, which is actually an important feature of AdGuard Home functionality.
In reality, only about 40-50MB is required for the Adguard upgrades right now which includes downloading the file, extracting and then copying the extracted file to the working directory. If you set the default log lengths to 24hrs by default, then even on my lowly MT1300, there should almost always be enough space to do upgrades.
BTW - my MT1300, per specs shows as having only 32MB but tmpfs shows a size of 122MB. Is tmpfs using a RAM drive in addition to the 32MB flash to achieve this space or are the specs incorrect?
The size of the AdGuard Home log files depend on the retention period and the volume of DNS requests over that time.
The log files on my GL-MT2500 currently total 31 MB for only 7 days retention. If I want 90 days retention, it may be 398 MB which is okay given 6.76 G free storage, but not for a number of other GL.iNet routers.
In actual fact, my GL-MT2500 is the secondary/backup DNS server on my network. I also have AdGuardHome running on a Synology NAS as the primary DNS server, which handles ~80% of the volume of DNS requests, has 4TB storage and has faster processing time. If I use the GL-MT2500 as my sole DNS server, then the AdGuardHome log files may be ~2 GB for 90 days retention.
“tmpfs” is an in-memory file system that has been decompressed. So it is larger than the flash firmware storage size.
Hi, thanks for that. However, I don’t think it is the solution when GL is planning an update considering it.
Most users don’t know how to do that. If I buy a device that promises to deliver quality and is fully functional with Adguard, I hope to do any changes on the web, not in command lines.
Finally I am trying to update, but I got this error in the command
Try opkg update first then opkg install file.
An method is simply just doing uname -m and send me that output but if the output is mips then you should be able to use my updater program. In general though you should keep opkg periodically updated.
My updater script already accounts for aarch64 so it should work but I’ve never tested specifically on your model. The good news is that the script won’t do anything without your input to confirm. You can try it out following the instructions on the githib page and if it finds all the necessary prerequisites, it will update your AGH to the latest version after your confirmation.
Thanks
I got this error
