Bug 762747 (GLUSTER-1015) - ls returns "File descriptor in bad state" after server down/up
Summary: ls returns "File descriptor in bad state" after server down/up
Keywords:
Status: CLOSED NOTABUG
Alias: GLUSTER-1015
Product: GlusterFS
Classification: Community
Component: replicate
Version: 3.0.4
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: Pavan Vilas Sondur
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-21 22:36 UTC by Vikas Gorur
Modified: 2010-06-22 22:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)
Client TRACE log (72.92 KB, text/plain)
2010-06-21 19:37 UTC, Vikas Gorur
no flags Details

Description Vikas Gorur 2010-06-21 19:37:47 UTC
Created attachment 235 [details]
XFree86 Xserver output for 1024x768 16bpp

Comment 1 Vikas Gorur 2010-06-21 20:41:41 UTC
Issue can be fixed by specifying

 option strict-readdir on

to the replicate volume.

Comment 2 Vikas Gorur 2010-06-21 21:15:42 UTC
Behavior is expected. Option "strict-readdir" fixes it. Perhaps strict-readdir should be the default?

Comment 3 Harshavardhana 2010-06-21 21:17:11 UTC
(In reply to comment #3)
> Behavior is expected. Option "strict-readdir" fixes it. Perhaps strict-readdir
> should be the default?

Isn't keeping this on a performance bottleneck?

Comment 4 Vikas Gorur 2010-06-21 22:36:56 UTC
Setup is GlusterFS 3.0.4, replicate with two subvolumes, no performance translators.

The bug was seen when the following sequence of operations were done:

# cd /mnt/glusterfs/test1

Kill glusterfsd on server1

# mkdir test2
# cd test2
# echo "hi" > file

Start glusterfsd on server1

# ls
.: File descriptor in bad state

Also, self-heal was not triggered on the test2 directory until a "cd .." was done on the client.

TRACE logs for the client are attached.

Comment 5 Garrett Prochnow 2010-06-22 19:19:37 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Behavior is expected. Option "strict-readdir" fixes it. Perhaps strict-readdir
> > should be the default?
> 
> Isn't keeping this on a performance bottleneck?

The whole point of using the replicate translator is redundancy....if the clients need to use readdir, it should be set by default.


Note You need to log in before you can comment on or make changes to this bug.