Re: RFC: implementation of package pools
On Fri, 20 Oct 2000, Anthony Towns wrote:
> Well, that might not be necessary: we might find that we top out the
> number of packages we want at 10k, and decide to focus more on just
> maintaining and enhancing those rather than packaging more stuff, or
Well, considered from a purely practical point of view, the BTS software
operates on a directory with a 100k files in it, it still works, and for
all the common operations the speed is still fine on ext2. Further, auric
has 1.5G of ram. That's alot of ram, in fact that is enough ram to store
dentries for the entire archive (it actually does this right now). Once
you get to that point filesystem performance is not terribly important.
In all honesty there is a fair chance that on auric one big directory
would not cause that much of a performance hit, but it would be utterly
unworkable. (Think ls over a ftp connection to find a package, over a
28.8. Ouch.)
> It's a best implementation strategy given our existing desires and
> constraints. One of which is programmer time, and another of which is
> acceptability to the existing ftpadmin people. It's not an academic
> solution, although obviously it's informed by academic pursuits.
Academic solutions almost never exist in the real world, virtually
everything is driven by compromise and engineering decisions (which are
all about tradeoffs).
> That'd be more useful for the BTS than the ftp system. (You can't
> guarantee all our mirrors will use said fs, eg)
Reiser anyone? Rumored to give quite good performance on the BTS dir.
> Academic solutions probably won't be directly applicable to Debian
> though. Debian's far too political and complicated and entrenched to end
> up with ideal solutions. So if you want to do something pristine and pure
The existance of an ideal solution within any political environment is
highly questionable IMHO..
> and *correct*, you're probably better off just writing a paper.
Right.
> > working on package categorization now, so you guys make sure that
> > you have some symlink-farm support :)
There is no way symlinks will used again - they have too many problems and
no benifits. :|
> Package categorisation should just go in the Packages file and be
> handled by console-apt or dselect, it doesn't need to be visible in the
> file system (and probably won't be: all those symlinks are actually a
> significant hit on mirror space and such, with the number of packages we
> already have).
Right.
Jason
Reply to: