[Gluster-devel] rename(2) on open file loose unsync data

[Amar Tumballi]

Can you try with disabling 'write-behind' and 'quick-read' ? We have these
type of tests in our QA which works fine on master branch as of now. Will
reconfirm the behavior with master on GNU/Linux.

-Amar

On Sat, Mar 31, 2012 at 10:32 AM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> I have hit a bug in glusterfs on NetBSD, but I wonder if NetBSD FUSE is
> the culprit, or if the problem is in glusterfs itself. If I rename and
> open file, the unsync data get lost (it is replaced by a chunk of
> zeroes).
>
> The test case below exhibit the bug. Does it happens on Linux too, or is
> it a problem in NetBSD FUSE?
>
> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <err.h>
> #include <sysexits.h>
>
> int
> main(void)
> {
>        int fd1, fd2;
>        char buf[] = "abcdefgh";
>        char buf2[] = "xxxxxxxx";
>
>        (void)unlink("tmp");
>        (void)unlink("tmp2");
>
>        if ((fd1 = open("tmp", O_CREAT|O_RDWR, 0644)) == -1)
>                err(EX_OSERR, "cannot open tmp");
>
>        if (write(fd1, buf, sizeof(buf)) != sizeof(buf))
>                err(EX_OSERR, "write failed");
>
>        if (rename("tmp", "tmp2") == -1)
>                err(EX_OSERR, "rename failed");
>
>        /* No bug if fd1 is closed or fsync'ed before rename */
>        (void)close(fd1);
>
>        if ((fd2 = open("tmp2", O_RDONLY, 0)) == -1)
>                err(EX_OSERR, "cannot open tmp2");
>
>        if (read(fd2, buf2, sizeof(buf2)) != sizeof(buf2))
>                err(EX_OSERR, "read failed");
>
>        (void)close(fd2);
>
>        printf("buf  = \"%s\"\nbuf2 = \"%s\"\n", buf, buf2);
>
>        return 0;
> }
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu at netbsd.org
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120401/043e5973/attachment-0003.html>