[LU-666] mdd depends on ldiskfs-only dynlocks feature Created: 07/Sep/11 Updated: 13/Oct/11 Resolved: 13/Oct/11 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.2.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Brian Behlendorf | Assignee: | Lai Siyao |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Story Points: | 1 |
| Severity: | 3 |
| Bugzilla ID: | 22,435 |
| Epic: | server |
| Project: | Orion |
| Rank (Obsolete): | 4886 |
| Description |
|
As discussed in Lustre bugzilla 22435 dynlocks are provided by the ldiskfs and are not a generic facility. They should be removed from the mdd-level to allow building --without-ldiskfs per Andreas's comment in 22435: https://bugzilla.lustre.org/show_bug.cgi?id=22435#c3 This change converts the instances of "struct dynlock_handle *" to a "void *" pointer which is safe because they are never dereferenced at this level. It also wraps the "struct dynlock" entry in the mdd_object with MDD_DISABLE_PDO_LOCK. This effectively limits all direct dynlock usage to the !MDD_DISABLE_PDO_LOCK case which is unconditionally disabled in the code. Presumable this code will simply be removed at some point which will fully resolve the issue. |
| Comments |
| Comment by Brian Behlendorf [ 07/Sep/11 ] |
| Comment by Peter Jones [ 07/Sep/11 ] |
|
Lai Could you please look into this one? Thanks Peter |
| Comment by Peter Jones [ 13/Oct/11 ] |
|
Landed for 2.2 |
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|
| Comment by Build Master (Inactive) [ 13/Oct/11 ] |
|
Integrated in Oleg Drokin : 69efa174743f5ad2425c0ccd951961ae356fed0d
|