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

Re: FSFS replication and the rep cache

From: Daniel Shahaf <danielsh_at_apache.org>
Date: Tue, 21 Aug 2018 15:10:14 +0000

Julian Foad wrote on Tue, 21 Aug 2018 14:12 +0100:
> * We could ignore the rep cache during commit-txn (in existing API:
> set fs_fs_data.rep_sharing_allowed = FALSE), then make a separate call
> to update the rep cache afterwards.

"A separate call to update the rep cache afterwards" --- something like
`svnadmin backfill-rep-cache -r 40:50` --- could be generally useful, to
admins who had disabled rep-cache or deleted rep-cache.db (intentionally
or otherwise) and want to rebuild the rep-cache without a dump/load cycle.

(To be clear, I'm not opining that the logic should be in svnadmin; that
was just a pseudocode example.)

> * We could change FSFS to allow selectively disabling part 2 (look up
> props) during the 'commit' step while keeping part 3 (update) enabled
> (split that flag into two), and disable part 2 only.
> With these first two options, the rep cache would deduplicate only file
> contents, and that is fine. Deduplication of properties is relatively
> minor.
> * We could change FSFS such that commit-txn no longer depends on the
> rep-cache content, by moving the props deduplication to the txn-building
> phase.
> * We could ensure the rep cache is synchronized across repositories
> before each commit-txn.

Who's "We" in the last sentence?

> Could I please hear your thoughts? How appropriate might it be to make
> such changes in FSFS, if they are potentially beneficial for other users
> of the FSFS API, or other considerations?

Thanks for sharing the wider context.

Received on 2018-08-21 17:10:25 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.