Post reply

Name:
Email:
Subject:
Tags:

Seperate each tag by a comma
Message icon:

Attach:
(Clear Attachment)
(more attachments)
Allowed file types: apk, doc, docx, gif, jpg, mpg, pdf, png, txt, zip, xls, 3gpp, mp2, mp3, wav, odt, ods, html, mp4, amr, apk, m4a, jpeg, aac
Restrictions: 50 per post, maximum total size 150000KB, maximum individual size 150000KB
Note that any files attached will not be displayed until approved by a moderator.
Anti-spam: complete the task

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Dhammañāṇa
« on: February 23, 2019, 11:11:33 AM »

Maybe a function that deletes older Versions made with in a timeframe of say 24h, or 48h as well, would be good, since the versions-producing replacment sessions are surely nevertheless able to fill the webspace within one or to days again.
It then might even not require to delete all older after the busy times at the beginning.
Posted by: Dhammañāṇa
« on: February 18, 2019, 08:01:40 PM »

Sadhu!
If necessary, the old revisions could still be restored from the backup if one can download the file. But it seems that Greensta is still having the same old problems with not being able to download large backup files (download stopping after 1 gigabyte). I have written an email to Greensta to inform about the problem.
My person does not think it is necessary to restore, still huge general modifications. How ever, if there is a backup available for some times, in cases, that's sure fine.
A description of the cleanup process is now written down here: http://accesstoinsight.eu/en/tech/maintenance
Sadhu!
...Good to know. Maybe the Cleanup plugin is a cleaner overall solution, already well-maintained by others. But with the cronjob now everything seems to be running fine, and it is easier to maintain one's own custom logic of what to clean up (i.e. keep first and last three at the moment).
I will try to add media attic and cache cleanup soon.
Sadhu!
Posted by: Moritz
« on: February 18, 2019, 07:27:36 PM »

Just to inform, it wouldn't keep the first three but some at the beginning, see http://accesstoinsight.eu/de/tipitaka/sut/an/an04/an04.036.than?do=revisions&first=80 for example.
Oops. The reason was that I had assumed without checking that files would be sorted by filename when reading directories in PHP. So the first and last 3 of a randomized list of revisions were kept for each file.

Now that is fixed. If necessary, the old revisions could still be restored from the backup if one can download the file. But it seems that Greensta is still having the same old problems with not being able to download large backup files (download stopping after 1 gigabyte). I have written an email to Greensta to inform about the problem.

A description of the cleanup process is now written down here: http://accesstoinsight.eu/en/tech/maintenance

Mr. LMS has offert some manual solutions with plugins, possible good in addition to a good cronjob general solution:

- https://www.dokuwiki.org/plugin:cleanup
- https://www.dokuwiki.org/plugin:clearhistory

and told that media attic can be seen similar.

Good to know. Maybe the Cleanup plugin is a cleaner overall solution, already well-maintained by others. But with the cronjob now everything seems to be running fine, and it is easier to maintain one's own custom logic of what to clean up (i.e. keep first and last three at the moment).
I will try to add media attic and cache cleanup soon.
And Mr. Michael points on setting to avoide media-revison saving general, which seems to be proper in this wikis case. No need to store them, better to give another name if keeping old is proper.

_/\_
Posted by: Dhammañāṇa
« on: February 18, 2019, 06:42:22 PM »

And Mr. Michael points on setting to avoide media-revison saving general, which seems to be proper in this wikis case. No need to store them, better to give another name if keeping old is proper.
Posted by: Dhammañāṇa
« on: February 18, 2019, 06:28:03 PM »

Mr. LMS has offert some manual solutions with plugins, possible good in addition to a good cronjob general solution:

- https://www.dokuwiki.org/plugin:cleanup
- https://www.dokuwiki.org/plugin:clearhistory

and told that media attic can be seen similar.
Posted by: Dhammañāṇa
« on: February 18, 2019, 07:26:36 AM »

Just to inform, it wouldn't keep the first three but some at the beginning, see http://accesstoinsight.eu/de/tipitaka/sut/an/an04/an04.036.than?do=revisions&first=80 for example.
Posted by: Dhammañāṇa
« on: February 18, 2019, 07:04:35 AM »

Sadhu. Sounds great.

It was at 11.2GB and is still high because made a lot of edits this days. Once general edits are done, it will be down to 2 or 4 GB.

In reagard of media, Atma tries o ask.

-> Attic-media Daten und cache gleich behandelbar wie für pages?

Possible good if making a page maintenance so that adjustments could be easier made by others later and storage is understood.
Posted by: Moritz
« on: February 18, 2019, 06:37:31 AM »

Cleanup cronjob is now running every hour.
It is set up to delete nothing which is newer than 30 days, and also to always keep at least the first three and the last three versions.
At the moment only cleaning up in "data/attic", but there are other places like "data/media_attic" (not much there at the moment), the cache (some gigabytes) and maybe more. Just not quite sure yet about how everything else works, not wanting to delete too much. So there is still room for improvement.
Disk space usage for accesstoinsight.eu is now shown as 8.02 Gigabyte. Not sure how much it was before.

_/\_

*  Now leaving for tonight. May all the deleted files find a fortunate rebirth, if not release into nibbana. ^-^
Posted by: Dhammañāṇa
« on: February 17, 2019, 06:42:21 PM »

Sadhu!
Posted by: Moritz
« on: February 17, 2019, 06:33:32 PM »

Vandami Bhante _/\_

Sorry, I was very busy lately. But it looks like the reason was found. Good to know what is happening to all this disk space and how to keep more of it available for use.
I am now making a backup of ATI.eu and will try to make a script for the cleanup cronjob later in the evening.

_/\_

Quote
Tried to download the over 500.000 files, but that may require days (25.000 solved). So possible delete manual folder for folder might be easier to keep the oldest versions in en: de: pt: zze origin. -> not so, it takes a huge of time, an hour for one folder.

I have already completed the backup with the Greensta backup function and am downloading it now. So the current state of the Wiki should be safe.

Deleting attic files with a cronjob script directly on the server later should run fast.

_/\_


Posted by: Dhammañāṇa
« on: February 17, 2019, 06:02:28 PM »

Tried to download the over 500.000 files, but that may require days (25.000 solved). So possible delete manual folder for folder might be easier to keep the oldest versions in en: de: pt: zze origin. -> not so, it takes a huge of time, an hour for one folder.
Posted by: Dhammañāṇa
« on: February 17, 2019, 05:25:08 PM »

A "cronjob", like found in giving into by Mr. Michael would be a solution , possible, but Atma fears to have to less knowledge to do not damage things by maintenance .

A programmer could possible add not to delete the oldest as well.
Posted by: Dhammañāṇa
« on: February 17, 2019, 10:46:20 AM »

It seems as if found the reason: Older Versiins

With every change the whole page is stored. Given 6300 pages+ and hundreds of changes each, explains why 1GB content grows fast to 12 GB.

The question is now how to solve it, given that there would be possible hundred-thousands of files manual to delete. Build up totally anew and delete them in attic all?

In the case it works that way and gives no errors, how to handle it in the future not to happen or give settings like "the oldest and the last month" of old versions.
Posted by: Dhammañāṇa
« on: February 17, 2019, 07:54:07 AM »

Reducing the time as made possible does not help. Atma asked also in DW-forum . Does Nyom Moritz have a not to much of his time using idea?
Posted by: Dhammañāṇa
« on: February 16, 2019, 09:04:10 PM »

Aramika   *

Dieses neue Thema (bzw. diese/r Beitrag/e) wurde  aus abgetrennten Beiträgen, ursprünglich in [ATI.eu] various errors , hinzugefügt. Für ev. ergänzende Informationen zur sehen Sie bitte das Ursprugsthema ein. Anumodana!
The new topic (or post/s) here are originaly from [ATI.eu] various errors . For eventual additionally information: please visit also the Topic of origin. Anumodana!

[Original post:]


Again full... it might have to do with the big amount of edits, possible storing all changes.

Quote from: admin page
sangham.net   5596.05 MB   7000 MB   7001 MB   5596.05 MB 7000 MB
zugangzureinsicht.org   687.72 MB   800 MB   801 MB   687.72 MB 800 MB
accesstoinsight.eu   12198.93 MB   12200 MB   12201 MB

Now reduced to 90 days from 366 store might possible help for now. Wondered why a possible 1,5 GB volume needs 12 GB. Lets see.