[Gluster-devel] trusted.glusterfs.version xattr

[Martin Fick]

--- Gordan Bobic <gordan at bobich.net> wrote:
> Martin Fick wrote:
> >  /dir1/dir2/file
> >
> >   file and dir2 are deleted
> >   dir2 is re-added
> >   file is re-added and dir2 version is now the
> >        same as it was before it was deleted.
> >
> > Same problem as before but one level higher. 
> > You would need to version all the way to the 
> > root, "/", for this to work, wouldn't you?
> 
> No. You just need to treat directories the same as
> any other file. When a create/delete operation 
> happens, the directory version gets bumped up.
> So removing and creating a subdirectory (or a file)
> would result in the created file/directory having a 
> major version 2 versions higher than the
> previous instance.

Think parent directory, not subdirectory.  If the 
parent directory of the file and the file itself 
are deleted and recreated you may end up with 
the same versions of both the parent directory and
file!

  Original creation process and versioning:

  /
 v1
  /dir1/
 v2   v1
  /dir1/dir2/
 v2   v2   v1
  /dir1/dir2/file
 v2   v2   v2  v1

Mirror goes off-line with version #s of dir2 and file
as: v2/v1.

-> file deleted

  /dir1/dir2/
 v2   v2   v3

-> dir2 deleted

  /dir1/
 v2   v3

-> dir2 recreated

  /dir1/dir2/
 v2   v4   v1

-> file recreated

  /dir1/dir2/file
 v2   v4   v2   v1

Uh oh, now if I look just at the version #s of dir2 
and file I get: v2/v1  these are the same as they 
were above when our mirror went off-line, the file 
looks like it is the same when in fact both it and 
its parent directory have been recreated!  

However, if we were looking at the versions all the 
way to the root, when the mirror went off-line we 
would have had: /v2/v2/v2/v1 and now we have: 
/v2/v4/v2/v1.  There is a chance that we are 
talking about different files now.  Of course, the
problem I see now is that the files could in fact 
have been the same even though the version number is 
different with this scheme!  Since the only version
# that is different is that of dir1 (v4), this could 
have been caused by simply adding two new files to 
that directory!  

We now have the reverse problem, possible resyncing 
when not needed.  This means that possibly every 
single subdirectory/file of a directory needs to be 
resynced.  Yikes, this problem would also be 
prevalent (although less intense) even when just 
using the parent's version # wouldn't it?  Every time
a directory is reversioned, all the files in it are
now reversioned?


>  > > Directory moves could create a similar problem:
>  > >
>  > >   /dir1/dir2/file
>  > >   /dir1/dir3/file
>  > >
>  > >   /file and dir2 deleted.
>  > >   dir3 moved to dir2 and happened to match file
>  > >     and dir2 version #s.
>  > >
>  > > but I think that versioning to the root would
> > > again solve this?
> 
> You don't need versioning up to the root, you just
> have to treat moves the same way as copy+delete from

> the versioning point of view. This doesn't mean you 
> actually have to copy+delete - you just have to 
> update the metadata as if you did.

I wasn't implying that a move was a special case,
rather that by moving the parent directory to a file
you could end up with the same problem that I describe
above where a file is a completely different file than
on the mirror, but both the file and parent
directory's version #s are the same.

-Martin



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ