Re: special provisions when etch makes it to archives?
> >And it might still be a good idea to split that large deletion into chunks,
> >because if several tens of thousands of files go away at the same time, that
> >could trip up some --max-delete settings.
> Curiosity, did you already calculate the number of deletions for etch?
> A long time ago I did it just to know how much disk would be saved by
> removing a release. I was surprised to see how little it saves because
> of the structure of the archive. It may have changed now though.
Of course our removal process keeps track of not deleting too many files
at once. Standard config for a Debian mirror is to limit it to 40k files
at once, we limit it to 10k at ftpmaster. I havent actually calculated
how many files are unique within etch, but I am sure it will be *WAY*
less than the 160k files etch alone has. (If someone really wants to do
this calculation, look into the indices/components directory on our
mirrors, it should be a simply substraction of all the files from
suite-oldstable list).
> >> for FILES in $INDICES ; do
> >> zcat $FILES | xargs cp --archive --target-directory=$TO_DIR --verbose
> >> --parents
> >> done
> >> </snip>
> >If its on the same filesystem, -l helps to save a lot.
> Then no action is necessary in the mirror, everything will happen
> automatically when the master does the hardlinking. If the archive is
> in the same filesystem in the master, of course. Is it?
archive and ftpmaster are two entirely seperate machines and archives.
--
bye, Joerg
Shut-up brain or I’ll stab you with a Q-Tip.
Reply to: