[Top][All Lists]

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

[Gnu-arch-users] Re: tla on nfs only

From: Stefan Monnier
Subject: [Gnu-arch-users] Re: tla on nfs only
Date: 15 Mar 2004 09:49:46 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> For each file,
> The first check tla does is stats against the revision library.  This is the
> cheapest check it can do.  If the files are hardlinks of each other, the
> working copy hasn't changed.

In my world, this *never* happens, so it's a complete waste of time.
Even if this works for you (i.e. you use --link), it still requires two
stats per file, so it's still slower than the inode-sig check below.
Sounds like a pessimization to me.

> If tla still don't know, it checks the file against its inode signature.

That's the good check: only one stat per file (rather than two above).

> If the file doesn't match its inode signature, tla does a whole-file
> binary comparison.

Sounds good.

> Even if the stats step is skipped, you were advocating removing inode
> signatures from the working directory, and that will force tla to do
> a whole-binary comparison of every file against the revlib.

No, I'm all in favor of the inode sigs in the working directory.
Especially since they're only an optimization: if the check fails, it's
no biggie.  I'd like to see the device-number check removed, tho, because
it makes the check fail much too often on NFS.
Also the work-tree inode-sigs need to be updated more often than just
during `commit' so they're more effective..

> If md5 signatures were implemented, you'd be doing whole-file comparisons
> against the md5 signatures instead.

I'm opposed to device numbers and inode numbers in the revlib inode-sigs
because they create problems when the check incorrectly fails: tla does not
dare to remove the revlib so you get an error and you need to fix
it manually.  Also the impact of not using a revlib because of an
incorrectly-diagnosed corruption can be much more than just performance
since rebuilding the revlib might require network access.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]