Re: [Gnu-arch-users] Re: corrupt library (failed inode signature validation)

[Miles Bader]

On Sun, Feb 15, 2004 at 06:44:01PM -0500, Stefan Monnier wrote:
> I have enough disk space.  I just want to minimize network use, especially
> on my laptop.  I'm quite willing to clean up my cache manually if it ever
> grows too large, although some automatic tool would be better to avoid
> pilot errors.

Sure -- but that's you.  [The point being only that it's not something that
should happen by default.]

> Bigger, sure, but "much bigger"?  Really?
> The set of patches don't seem to use that much more space than the few
> revision kept in my library (at least for the Emacs stuff I've used so far).

I depends on the details, I suppose.  If it mirrors cached revisions, it
could be _much_ more, so I suppose it shouldn't do that.

(also see below)

> > and also introduces the question: when does it make the mirror?
> 
> First time you access a new archive?
> 
> > If it's in response to an attempt to access a particular bit of
> > information, that could slow down the request dramatically -- and you
> > might never actually follow through and _use_ the mirrored information.
> 
> Why would that slow things down so much?  It shouldn't require any
> additional network communication and would just involve creating a few dirs,
> and stashing the data sucked from the archive into the cache.
> What am I missing?

A lot of arch access to an archive only looks at the meta-info files, but
the arch mirroring process -- though it allows you to mirror specific
branches/revisions -- grabs _everything_.  That means that if you so
something like `tla abrowse ...' on a heretofore unused archive, it will
_mirror the entire archive contents_ first, which could take a while.

You could do the auto-mirroring only for commands that actually use the real
data (e.g., replay, update, etc)., but if you use greedy revlibs, I think
that's actually of fairly limited utility -- you often don't _need_ the real
data multiple times.

In my experience the bandwidth-saving aspects of a mirror actually matter
more for the meta-info than for the actual data, so another possibility would
be to allow `partial mirrors', where revision directories can contain
meta-info; these might be much faster to update (depends on the specific
details like network latency, revision size, etc).

The other instance where I often see redundant data fetching is doing
something like `tla changes' after using `tla replay' to update a project
tree -- replay doesn't actually use the revlib, so it fetches the revision
changeset again to create the greedy revlib entry.

-miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?