On Thu, Aug 01, 2013 at 07:04:15AM +0200, Branko Čibej wrote:
> On 01.08.2013 05:38, Daniel Shahaf wrote:
> > On Thu, Aug 01, 2013 at 05:31:56AM +0200, Branko Čibej wrote:
> >> On 01.08.2013 04:17, Daniel Shahaf wrote:
> >>> Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
> >>>> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <ben_at_reser.org> wrote:
> >>>>
> >>>>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> >>>>> <philip.martin_at_wandisco.com> wrote:
> >>>>>> Looking at the repository path ('CONVERSION' and 'test') and the fact
> >>>>>> that the error vanished when httpd was restarted is it possible this
> >>>>>> involved a temporary repository being replaced by another repository at
> >>>>>> the same path with the same UUID. If that happens I think apache may
> >>>>>> have been using the in-memory cache associated with the old repository
> >>>>>> when accessing the new repository.
> >>>>> Realistically the UUID really shouldn't be used by caching to decide
> >>>>> if it's looking at the same repo. Since it's exposed to clients users
> >>>>> doing dump/load cycles are going to modify repos and end up with the
> >>>>> same UUID. I'd suggest that we add another UUID that isn't exposed to
> >>>>> the client and that svnadmin can't modify with load. The cache system
> >>>>> should use this UUID for cache purposes.
> >>>>>
> >>>> +1. Let's call that UUID "instance ID".
> >>> How about the inode number of the db/ directory?
> >> Very portable, extremely cross-platform,
> > apr_file_info.h
> >
> >> does not rely on details of filesystem design at all. :)
> > When you design a filesystem that doesn't have a db/ directory at all, let me
> > know.
>
> Not to mention that inodes can be reused. Do you really want to design
> that kind of Heisenbug?
How do you propose to avoid it? If you just create a db/instance_uuid
file, you'd have a heisenbug if people use 'zfs rollback' to restore
a snapshot.
Received on 2013-08-01 07:33:09 CEST