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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx > > > http://lists.nongnu.org/mailman/listinfo/gluster-devel > > > . > > > > > > > > > > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@xxxxxxxxxx > > 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
