[Gluster-devel] posix-locks: running ls on file (or directory containing file) while file is being written causes failure

Anand Avati avati at zresearch.com
Tue Sep 25 05:44:38 UTC 2007


Kevan,
 this bug is now fixed in TLA 492. This bug used to occur when a new client
did a fresh lookup of the file. thus it would happen only when the second
file was remounted, or if you started dd on a yet another new file. Please
upgrade to 492 and let us know if it works for you.

thanks for your patience :)
avati

On 9/25/07, Anand Avati <avati at zresearch.com> wrote:
>
> Kevan,
>   It took a while to reproduce this bug. This happens once in a while and
> is not consistantly reproducible in our setup. We are working on fixing
> this. It does not seem to be happening on every listing while writing to a
> locked file.
>
> thanks for reporting!
> avati
>
> On 9/25/07, Kevan Benson <kbenson at a-1networks.com> wrote:
> >
> >
> > Can anyone corroborate or refute?  It seems like a fairly major bug, I'd
> > be interested in whether anyone else can reproduce it or if it seems to
> > be limited to my testing.
> >
> > It should be fairly easy to test.  If you are using posix locks, try
> > listing a file as it's being written.
> >
> > Kevan Benson wrote:
> > >
> > > glusterfs 1.3.1 TLA 489 / Fuse 2.7.0 GLFS3
> > >
> > > When writing a file from a client, an operation that does a listing on
> > > that file from another client while the file is being written causes
> > > the write operation to fail when the posix-locks feature is used.
> > >
> > > I can replicate this with multiple config types, with AFR and Unify on
> >
> > > the server, or on the client, or in the simplest case, with absolutely
> > > no special xlators besides posix-locks and a single server.  Here's
> > > the configs for that case:
> > >
> > > Here's what it looks like:
> > > # dd if=/dev/zero of=/mnt/glusterfs/testfile.10MB bs=1k count=10k
> > > dd: writing `/mnt/glusterfs/testfile.10MB': Bad file descriptor
> > > 4006+0 records in
> > > 4005+0 records out
> > > dd: closing output file `/mnt/glusterfs/testfile.10MB': Bad file
> > > descriptor
> > >
> > > On the other client I'm simply running this to cause the error:
> > > # ls /mnt/glusterfs/
> > >
> > > Here's the configs for the simplest case:
> > >
> > > # server.vol
> > > volume share
> > >        type storage/posix
> > >        option directory /exports/test
> > > end-volume
> > >
> > > volume brick
> > >        type features/posix-locks
> > >        subvolumes share
> > > end-volume
> > >
> > > volume server
> > >        type protocol/server
> > >        option transport-type tcp/server
> > >        option listen-port 6996
> > >        subvolumes brick
> > >        option auth.ip.brick.allow *
> > > end-volume
> > >
> > > volume trace
> > >        type debug/trace
> > >        subvolumes server
> > >        option debug on
> > > end-volume
> > >
> > >
> > > # client.vol
> > > volume brick
> > >        type protocol/client
> > >        option transport-type tcp/client
> > >        option remote-host 172.16.1.81
> > >        option remote-port 6996
> > >        option remote-subvolume brick
> > > end-volume
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Gluster-devel mailing list
> > > Gluster-devel at nongnu.org
> > > http://lists.nongnu.org/mailman/listinfo/gluster-devel
> > > .
> > >
> >
> >
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
>
>
>
> --
> It always takes longer than you expect, even when you take into account
> Hofstadter's Law.
>
> -- Hofstadter's Law




-- 
It always takes longer than you expect, even when you take into account
Hofstadter's Law.

-- Hofstadter's Law



More information about the Gluster-devel mailing list