[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 1 Jul 2011 08:31:02 +0400

On Fri, Jul 1, 2011 at 02:57, Peter Samuelson <peter_at_p12n.org> wrote:
>
> [Hyrum K Wright]
>> I like this idea, but it would seem to introduce an additional stat()
>> call* for every attempt to fetch a revprop, because you'd first have
>> to check the "old" location, and then the packed one.
>
In simple approach: yes, we have to. But we already have
db/min_unpacked_revprop and we can update it when user modifies the
revprop.
This depends how often we expect revprop to be changed? I assume that
revprops are changed infrequently.
But I think that for server extra stat() is not so important as for
client and working copy library. Anyway when we access SQLite database
it checks for .db-journal and .db-wal files.

> Technically not an extra stat(), but an extra open().  Not the same.
> Especially since the "common case", as you put it, is that the open()
> returns ENOENT, file not found.  _That_ case may or may not be
> expensive, but it's quite different from the usual consideration of
> whether stat() is expensive.  Not least because stat() is usually
> considered in context where a file _does_ exist and various information
> about the file gets looked up to populate the stat structure.
>
Btw on Windows dry open() takes a lot more time than stat(). I don't why.

-- 
Ivan Zhakov
Received on 2011-07-01 15:38:29 CEST

This is an archived mail posted to the Subversion Dev mailing list.