Bug #11254
closedgetattr from one client stalls indefinitely while another client keeps modifying file
0%
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.
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.
Updated by Zheng Yan about 9 years ago
- Status changed from New to Fix Under Review
Updated by Greg Farnum about 9 years ago
- Status changed from Fix Under Review to Resolved
Merged to master in commit:0f2de92db3f6e9edbabf36c3065f847fdfb7bb98