Per my earlier posts, the issues with the /JFFS + AC86U + many AMTM scripts (J* scripts) which default to using the /JFFS, have to do with the heavier I/O workload actually hitting the /JFFS. The J* scripts write A LOT to the /JFFS file system unless you set them to use the /USB filesystem. Under 384.19 that higher I/O rate appears to lead to the NAND the /JFFS is running on not being able to perform GC (garbage collection) b/c it cannot juggle and consolidate all the "used but not released" space being deleted with the blocks it needs to perform that consolidation properly. The TLDR: details on how NAND works is beyond the scope of this thread. But quick summary for those that care...is when the /JFFS NAND is written to so often, it seems with 384.19 the /JFFS NAND does not have time (or space) to properly perform GC (garbage collection). A symptom of that is GC and other related errors start appearing. When that happens, the /JFFS becomes "read-only / out-of-space" and it's game over. Most of us who had been running the 384.18 + many of the AMTM scripts were using the /JFFS as the storage target. Doing the same on 384.19 seems to lead to the GC issues. At first it was blamed on "you have corrupt files" on the existing /JFFS which one backed up and restored it properly and that could be very true. But then 384.18 + same scripting was not generating nor was the NAND complaining about GC errors and was running great for months. YMMV.
For those of you with an AC86U + 384.19 + running LITTLE ELSE from AMTM or just a handful of custom scripts which do not hammer the /JFFS with I/O, then all indications I have, are you will likely to have few issues with AC86U + 384.19 if you follow the guidelines.
Others have have been reporting wireless issues... but I have seen none of those b/c I fix the channels to set bands, and turn off all the "Smart" stuff and few other wireless BP which are documented for stability elsewhere in our community.
My current 384.19 + AC86U + several (but not all of the J* scripts) has now been up ~ 10 days. Before it would stay up maybe 24 hours before rebooting itself or start having GC issues. (I also turned off AI Protect which stopped the unplanned reboots) I've gotten this far only after several "AC86U ASUS HARD Factory Resets" (look that up) and starting over from ground zero with every setting on every page. The family was howling about the constant issues so at this point, I'm just leaving it be for now until I get all the J* scripts running again without /JFFS NAND or other reboot issues. Stay safe, stay alive.
For those of you with an AC86U + 384.19 + running LITTLE ELSE from AMTM or just a handful of custom scripts which do not hammer the /JFFS with I/O, then all indications I have, are you will likely to have few issues with AC86U + 384.19 if you follow the guidelines.
Others have have been reporting wireless issues... but I have seen none of those b/c I fix the channels to set bands, and turn off all the "Smart" stuff and few other wireless BP which are documented for stability elsewhere in our community.
My current 384.19 + AC86U + several (but not all of the J* scripts) has now been up ~ 10 days. Before it would stay up maybe 24 hours before rebooting itself or start having GC issues. (I also turned off AI Protect which stopped the unplanned reboots) I've gotten this far only after several "AC86U ASUS HARD Factory Resets" (look that up) and starting over from ground zero with every setting on every page. The family was howling about the constant issues so at this point, I'm just leaving it be for now until I get all the J* scripts running again without /JFFS NAND or other reboot issues. Stay safe, stay alive.
Last edited: