[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