Bug #11254: getattr from one client stalls indefinitely while another client keeps modifying file - CephFS - Ceph

Actions

Copy link

Bug #11254

closed

getattr from one client stalls indefinitely while another client keeps modifying file

Added by John Spray about 9 years ago. Updated about 9 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Target version:

% Done:

Source:

other

Tags:

Backport:

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Component(FS):

Labels (FS):

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

Reproduce with two fuse clients on a vstart cluster.

Mount client A, and do nothing in it initially.
Mount client B, and run a loop like "touch hotfile ; while(true) ; do chmod +x hotfile ; chmod -x hotfile ; date ; done"
Try to do an "ls -l" in client A

Client A issues a getattr on hotfile, which gets stuck.

While it's fine that we don't have any general QoS/fairness yet, we need something that respects the fact that while client B still has outstanding modifications on a file's metadata, client A has been waiting for longer and should get a chance. It doesn't have to be fast, but there should be a way for it to eventually progress.

Actions

Copy link

Updated by Greg Farnum about 9 years ago

This is odd; did you do any digging into it?

There is some special code around getattr to try and make it not totally suck, but in general the getattr request should force a flush of everything and a release of caps from client B back to the monitor, which can then serve client A's getattr and return caps to client B.

Actions

Copy link