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

> -----Original Message-----
> From: Peter Samuelson [mailto:peter_at_p12n.org]
> Sent: 30 June 2011 23:58
> To: dev_at_subversion.apache.org
> Subject: Re: Does fsfs revprop packing no longer allow usage of traditional
> backup software?
>
>
> [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.
>
> 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.

Ok, but a) why can't the list of unpacked revprop files be cached at startup and updated as revprops are edited. If this is too much trouble, b) why not write a list of edited revprop files to a single file instead - this option may not help that much, but would at least keep the 'index' file in the OS fs cache and would prevent checking the disk for lots of revprops when returning log history and the like (ie the system would only need to read those files that you know are there, removing the need for stat calls)
Or of course c) store the list of edited, unpacked revprops in a sqlite DB table.

When svnsadmin pack is run, the cache, file, or table would just be wiped so there's little maintenance required - you will need to rename or delete the unpacked shards as the pack operation runs, or prevent read and writes to revprops during this operation.

Andy
Received on 2011-07-01 16:07:00 CEST