On Mon, May 12, 2008 at 3:01 AM, Martin Fick <mogulguy@xxxxxxxxx> wrote: > --- Derek Price <derek@xxxxxxxxxxx> wrote: >> Never mind, I thought that, using your algorithm, >> it was possible to create files in two different >> directories with identical version numbers, then >> move the directories around to swap the paths of >> the files with the same version number, but as I >> tried to come up with an example, I discovered that >> it looks like it isn't possible, starting with an >> empty file system. > > Well, I was wondering the same thing, and although I > haven't come up with an example, I am still tempted to > think that it might be possible and that this solution > is still too complicated. > > So the more I think about it, the more that a globally > unique sequenced id might be more appropriate. > However, I am not sure why in your suggested scheme > that you are not actually > making the id unique? When changing a file, > change the version#, but not the id of the parent > directory. The sequence # should only be incremented > on creations, not changes. This way each file/dir has > a unique id (which replaces the timestamp) and a > version #. All the moving in the world of the > file/dir will never cause two files/dirs to be > confused with each other. This is very simple and > much more reliable than timestamps. It seems so > simple that it should be a quick drop in replacement > for the timestamp method with barely any code changes? > > The only downfall to this scheme is that one must keep > track of the sequence. Perhaps this could be > the id of the top level directory (since it cannot > move), or simply add another attribute to the top > level directory to keep track of this. Martin, Avati came up with a similar idea during our discussion here. Having a unique-transaction-id instead of "create time" will fix things. I think there are no pit falls, have to see if it covers all possible cases. Thanks Krishna > > This scheme seems simpler and more reliable than > either of the others, and it will work well with > extent based quick healing (the method that was > compared to rsync method that was discussed earlier in > another thread), and efficient moves if coded > properly. If efficient moves are not currently > implemented (they do not seem to be on healing), they > could easily be addressed by the quick healing system > by storing inodes of moved files/dirs so that even on > heals these inodes can be preserved and need not be > recreated! > > -Martin > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
