On Fri, 2005-04-01 at 11:06 -0500, Aaron Bentley wrote: > >>2) The flat-revision subdirectory structure in ~/.arch-cache leads to > >>huge directories, this is not scalable. > > The arch cache doesn't list directories, so the O(n^2) directory listing > time on certain silly filesystems doesn't affect it. In what was is it > not scalable?
directory traversal will incur this overhead though, and we do traverse. I'm not sure that this is a problem for us though - even on such bad filesystems, the kernel should cache the result after the first read. > >> Is not version/patchlevel > >>structure more balanced > > For my money, it doesn't solve anything. There are archives with > thousands of revisions per version, and archives with huge numbers of > versions. > > And of course, it's no help at all for archives with one version. > > > and more consistent? > > The Cache was there first. Why should it be the one to change? IMO it doesn't .. being a separate object, I don't see there being a consistency argument at all. > > * just grouping revisions by archives leads to too big > > directories, that's not a good use filesystem storage. > > If you really want to solve the too-big directories issue, you'll need a > more sophisicated approach than just splitting the revision name off the > end. Yah. Rob
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
