Fwd: [Gluster-devel] proposals to afr

[Alexey Filin]

addition: It's impossible to reset flag with many concurrent "sessions"
without extra info, because they are closed independently and set flag says
nothing about is being closed "session" the last one or not, it is a counter
which says it. Probably such a counter exists in glfs already to count
"multiple references" (?):

http://fuse.sourceforge.net/wiki/index.php/FAQ

"...Wouldn't it be simpler if there were a single close() method?

No, because the relationship between the close() system call and the release
of the file (the opposite of open) is not as simple as people tend to
imagine. UNIX allows open files to acquire multiple references

* after fork() two processes refer to the same open file
* dup() and dup2() make another file descriptor refer to the same file
* mmap() makes a memory mapping refer to an open file

This means, that for a single open() system call, there could be more than
one close() and possibly munmap() calls until the open file is finally
released."


On Oct 26, 2007 8:34 PM, Alexey Filin <alexey.filin at gmail.com> wrote:

> On 10/25/07, Krishna Srinivas <krishna at zresearch.com> wrote:
>
> > So during open(), if version is same if the trusted_afr_open is set
> > and file is not open, then it needs repair. As of now I dont see any
> > problem with this algorithm but need to assess how complicated
> > it is to implement it. Because the more we do state maintenance,
> > the more the race conditions we will have to handle (that is a very
> > general statement though)
>
>
> I propose to use the algo with implemented one checking file mtime and
> size. The new algo helps to detect inconsistency when sizes are equal and
> mtimes differ slightly but contents differs (can happen when application
> didn't change size, instead it changed some bytes before crash), the old one
> helps to detect inconsistency when admin placed on childs different files
> with the same full name (the flag is not set).
>
> Will keep you guys informed regarding this.
>
>
> thanx, Alexey.
>
> Thanks
> > Krishna
> >
> >
>