[Top][All Lists]

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

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: tla on nfs only
Date: Mon, 15 Mar 2004 10:37:17 -0500
User-agent: Mozilla Thunderbird 0.5 (X11/20040217)

Stefan Monnier wrote:
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.

In my world, it's faster.

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.

We had to do the stats anyway, to make sure that the file type and permissions haven't changed. That code reuses the lstat results that are already necessary, so it's zero-cost.

Also the work-tree inode-sigs need to be updated more often than just
during `commit' so they're more effective..

I don't see the need here. Are you frequently modifying and undoing large numbers of files? Because for the 3-files-have-been-reverted case, it's just not worth it.

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.

Yeah, but NFS requires network access too :-)

Perhaps what we need is a gen-inode-sigs command, so the user can assert that the revlib is okay. (presumably after an md5sum check or something)


Aaron Bentley
Director of Information Technology
Panometrics, Inc.

reply via email to

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