Skip to main content

Any known current issues (or recently resolved) with Friendica dev storage cleanup?

Friendica Support reshared this.

I don't know any problems.
Thanks @Michael Vogel ... I should have mentioned I did search for open & closed issues that might relate, too, unsuccessfully. I appreciate the response, will keep my eyes open and will probe around a bit.
I switched back from storage to DB a several month ago.

My storage was humongous (30+GB), despite the DB clean-up enabled and very short time frames.

I used to run a major news relay and assumed that this resulted in the mega size storage. But when I discontinued the relay the storage never got smaller. I initially thought that directory permissions were set incorrectly, but I could see any obvious faults.

Eventually I switched back to DB and initiated the transfer process. This reduced the storage to some degree, but didn't fully work. Several attempts of moving back into the DB incrementally reduced the storage, but I was not able to entirely clean up the storage.

So I think there is something wrong with the storage clean-up mechanisms. At the time I had a brief discussion with Michael, but I hadn't enough time to toughly troubleshoot it and assumed that it might have been an idiosyncratic setup.
Thanks, @Andy H3 for your comment. I'm hoping I'll have a few minutes today to see if I can validate any of the on-disk storage, see if I can track down anything in the DB that makes me say "aha, that shouldn't still be here"
I think I have the same problem. Seit dem Wechsel auf den aktuellen Stable.
See my post here:
Der Speicherbedarf nimmt rapide zu. Mittlerweile verdoppelt.
Memory or storage? Looking to just discuss the on-disk (external or DB) storage piece in here.
If I understand Michi's comment correctly, it means his on-disk storage requirements have doubled.
Yes, that's what I mean. The disk-storage.
Hmm... In just a few checks of the files sitting around in my storage, I believe I may have found an orphaned file.

Storage folder has ./7a/85/ee7eb709f7584770216f6dc7eba245a343a2b6a7853c05b643ed4c5b9ff2

Grepping the entire database for the 'ee7eb...' string produces no results... I presume that if there's no reference to this filename in the DB it's orphaned, right?

Did anyone ever build a script to check for orphaned storage files?
Have found a second one... I think this could well be the issue - or, at least, an issue.
I am reopening this thread because I am having the same problems with a massively grown database. I noticed the problem in July. The database grew from 7 to 22 GB within a short time. My instance is relatively small with two active users.
Do you use the DB only or do you have a disk storage too, @Montag ?
Do we actually have an issue open on this?
Now we have an open Issue: 10732