[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: