[LU-405] NFS4 reexport fails with ll_find_alias()) ASSERTION(last_discon == NULL) Created: 09/Jun/11 Updated: 17/Jun/11 Resolved: 17/Jun/11 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.1.0 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Oleg Drokin | Assignee: | Oleg Drokin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Bugzilla ID: | 20,055 |
| Rank (Obsolete): | 4980 |
| Description |
|
This is basically the same issue as bug 20055. NFS lookup path is quite different than that of normal VFS and as the result a number of disconnected dentries might appear on Lustre inode. We probably jus tneed to have the same workaround as in 1.8 - to disable the assertion |
| Comments |
| Comment by Andreas Dilger [ 09/Jun/11 ] |
|
As part of Fan Yong's work to redo the statahead code to play more nicely with the dcache, I also want him to investigate reworking the entire llite VFS code to use more modern dcache interfaces like d_find_alias(), d_obtain_alias(), d_splice_alias(), etc. I have a feeling that with the introduction of other cluster filesystems into the kernel that the problems we had back in the 2.4 days are gone, and our conditional code for building against those kernels should also be removed. As well, the 2.6.38 kernel introduced significant changes to the dcache (lockless lookup) and we should be prepared to run on such newer kernels sooner rather than later. |
| Comment by Oleg Drokin [ 09/Jun/11 ] |
|
A bit of refactoring work was started already. |
| Comment by Peter Jones [ 09/Jun/11 ] |
|
Hmmm. Would it not make sense to use an existing proven workaround for 2.1 and defer the re-engineering until 2.2? |
| Comment by Oleg Drokin [ 09/Jun/11 ] |
|
I don't think Andreas is proposing to not deploy the workaround, rather this is some future work outlined by him. |
| Comment by Peter Jones [ 09/Jun/11 ] |
|
Ah ok, then it would probably be best to track under a separate ticket |
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Build Master (Inactive) [ 16/Jun/11 ] |
|
Integrated in Oleg Drokin : a1b2d35d18884c4c785dc5ab4978d70a2b9ba864
|
| Comment by Peter Jones [ 17/Jun/11 ] |
|
Landed for 2.1 |