Bug 201015 - GFS2 readdir - NFS interface
Summary: GFS2 readdir - NFS interface
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Whitehouse
QA Contact: Brian Brock
Depends On:
Blocks: 204760
TreeView+ depends on / blocked
Reported: 2006-08-02 09:30 UTC by Steve Whitehouse
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-09-22 09:51:47 UTC

Attachments (Terms of Use)
Message from Jan Engelhardt (3.22 KB, text/plain)
2006-09-05 10:55 UTC, Steve Whitehouse
no flags Details

Description Steve Whitehouse 2006-08-02 09:30:33 UTC
There are two interrlated problems here:

1. We have a different readdir path for NFS compared with "normal" readdir due
to different locking requirements. The NFS path is slower. This might need to be
resolved at the NFS end rather than the GFS end, but I'm making this a GFS2 bug
for now until that can be looked at in more detail.

Ken Preslan described the reasons for having the different code for NFS in the
document he wrote just before he left.

2. We use the name of the current process as a way to switch between the NFS and
"normal" readdir behaviour. This is certainly wrong. At the very least we might
be able to use __builtin_return_address(0) for this since we only have a single
code path which needs the NFS behaviour.

Comment 2 Steve Whitehouse 2006-09-05 10:55:36 UTC
Created attachment 135534 [details]
Message from Jan Engelhardt

The message I've just attached contains a suggestion for making a change to the
selection of the NFS path vs the "normal" path. It is a much better test than
the current one of guessing according to the name of the process.

Long term of course, we still want to eliminate the second code path
completely, but thats a rather more long and involved job.

Comment 5 Steve Whitehouse 2006-09-20 10:12:00 UTC
I've now removed the "NFS only" path from readdir. Having looked at this in a
bit more detail, I'm not so sure that the deadlock can actually occur anyway. I
have a feeling that the situation mentioned in the notes which Ken Preslan left
us is not relevant any more since we lock directories before their content
anyway now, and use the old "must lock in order" rule to break deadlocks at the
directory level (in rename) first and again when locking the inodes at the next
level down. I don't think we ever lock more than two levels at a time. Rename
seems the only likely thing that we might deadlock against and I think we are
safe there.

Comment 6 Steve Whitehouse 2006-09-22 09:51:47 UTC
I think we can close this one now.

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