Bug #232
closedESTALE on many copies
0%
Description
Discovered while exploring #229.
To reproduce:
Start up a multi-mds system in ceph dir.
Mount ceph with cfuse.
Copy ceph dir into cfuse (use a pre-made copy so this can't become recursive).
Eventually you start getting ESTALE responses on everything.
It looks like this is happening when you get an inode allocated on one mds but the parent dentry is on another MDS (and attempts to determine auth return the parent dentry's MDS), but I haven't worked out exactly what's causing the problem or how it's occurring.
Updated by Greg Farnum almost 14 years ago
So this is happening when the client tries to create and open a new directory after the parent directory's auth mds has changed. The client sends the create request to the old auth, the old auth replies with a forward, and the client forwards to the new auth and gets a new vino in response. But the client doesn't update its auth data, because the authority choosing is old and crusty. Which means that when it tries to open the new directory, it does so on the old authoritative mds, which has never seen the vino it provides and responds with ESTALE.
So now I'm re-working the mechanisms by which the userspace client chooses which mds to send requests to.
Updated by Greg Farnum almost 14 years ago
- Status changed from In Progress to Resolved
Done by 1bd46c0480b2d6b120773b4b122de6cd68861778, along with a number of other issues.
Updated by John Spray over 7 years ago
- Project changed from Ceph to CephFS
- Category deleted (
11)
Bulk updating project=ceph category=ceph-fuse issues to move to fs project so that we can remove the ceph-fuse category from the ceph project