On Wed, Aug 06, 2014 at 07:41:31AM -0400, Greg Troxel wrote:
> > Oh well, if I may dream we could even make repair work like that
> >
> > ls <conflict>/.codactl/replicas/
> > diff <conflict>/.codactl/replicas/{server1,server2}
> > diff <conflict>/.codactl/replicas/server1 <conflict>/.codactl/local
> > echo server2 > <conflict>/.codactl/prefer
> >
> > Which could possibly be worth to be available even if <conflict> is not a
> > conflict but a healthy file or directory, just in case, like "cfs expand".
> 
> That in concept sounds good.

To be picky against myself, the example above would harldy work
on anything which is not a directory, as the kernel could become
upset before passing any data to Venus.

On the other side e.g. letting Venus react on a reserved name suffix
like <object>%.codactl/[....anything-we-might-need]
would make it universally applicable to every object (and of course
disallow any name ending with "%.codactl" or whatever the magic string
would be).

Alternatively .codactl directory could be assumed side-by-side
with the object in question, like

 <object>                                      (file or dir or conflict)
 .codactl/<object>/<virtual-fs-like-interface> (the interface)

which probably is a bit cleaner.

This will become tricky when the object in question is a volume root
directory but I guess no worse than what repair handles today.

> I don't understand the notion of using xattr for control.  They are
> extra properties stored on files, and it seems semantically abusive to
> write them as a control operation.   (Having .codactl is also a bit
> abusive, but it's s single clean break.)

I do not like polluting the name space with "magic names" but this
is practical (and could be made safe by choosing a long and randomly
generated "magic" string). In practice the collision risk is apparently
not very important - I never heard anyone to complain about ".zfs" :)

Regards,
Rune