Bug 201015 – GFS2 readdir - NFS interface

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 201015 - GFS2 readdir - NFS interface

Summary:	GFS2 readdir - NFS interface

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Red Hat Enterprise Linux 5
Classification:	Red Hat
Component:	kernel (Show other bugs)
Sub Component:
Version:	5.0
Hardware:	All Linux

Priority	high Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Steve Whitehouse
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:	204760
	Show dependency tree / graph

Reported:	2006-08-02 05:30 EDT by Steve Whitehouse
Modified:	2007-11-30 17:07 EST (History)
CC List:	2 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2006-09-22 05:51:47 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Message from Jan Engelhardt (3.22 KB, text/plain) 2006-09-05 06:55 EDT, Steve Whitehouse	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Steve Whitehouse 2006-08-02 05:30:33 EDT

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 06:55:36 EDT

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 06:12:00 EDT

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 05:51:47 EDT

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.