Disk usage increase on download server / mirrors

Hannu Nyman hannu.nyman at iki.fi
Wed Nov 25 10:16:44 EST 2020


Baptiste Jonglez kirjoitti 25.11.2020 klo 1.37:
> On 21-07-19, Jo-Philipp Wich wrote:
>> Hi Baptiste,
>>
>> I agree that we should start purging the oldest kmod archives. I'd
>> propose dropping a kmod archive directory whenever it exceeds the age of
>> 6 months.
> This looks like a good idea.
>
> To expand one my previous email, here are some numbers for snapshots:
>
> - current total space (targets + packages): 208.0 GiB
> - cleaning up kmods from > 6 months ago: 144.1 GiB
> - cleaning up kmods from > 3 months ago: 120.0 GiB
> - cleaning up kmods from > 1 month  ago: 95.7 GiB
>
> So, snapshot kmods are responsible for about +10 GB of storage each month.
>
> And for releases (18.06-SNAPSHOT and 19.07-SNAPSHOT):
>
> - current total space (targets + packages): 682.9 GiB
> - cleaning up kmods from > 6 months ago: 610.3 GiB
> - cleaning up kmods from > 1 months ago: 597.4 GiB
>
> If we clean up [snapshot kmods > 6 months] and [stable snapshots kmods > 1 months],
> we gain 150 GB.
>
> Here is what I used on a mirror to test:
>
>    $ find snapshots/targets/ -type d -wholename '*/kmods/*' -ctime +180 -exec rm -r '{}' \;
>    $ find releases/*SNAPSHOT -type d -wholename '*/kmods/*' -ctime +30 -exec rm -r '{}' \;
>
> Thanks,
> Baptiste


I would shorten the times quite much more.

I feel that nobody should be using release-branch snapshots and expect to be 
able to download kmods later. The role of release-branch snapshots is mainly 
for continuous compile testing. I think that the kmod lifetime should be at 
maximum 1 month, but might be just two weeks quite as well. If somebody want 
to use the HEAD of a release branch, he could just as well compile firmware 
by himself.

Regarding master snapshots, the reasonable time might be something like 3 
months (instead of 6). Master develops continuously, and I don't see the need 
to support 6-month old bleeding edge... That edge has dulled quite much by 
then :-(





More information about the openwrt-adm mailing list