[LU-5099] Transfer the object's type via dio_insert() API to allow OSD set remote object type correctly Created: 26/May/14 Updated: 09/Jul/14 Resolved: 09/Jul/14 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.6.0 |
| Fix Version/s: | Lustre 2.6.0 |
| Type: | Bug | Priority: | Critical |
| Reporter: | nasf (Inactive) | Assignee: | nasf (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | HB | ||
| Severity: | 3 |
| Rank (Obsolete): | 14077 |
| Description |
|
When the LFSCK found a dangling name entry, it may be required to re-create the lost remote MDT-object. The LFSCK needs to know the file's type for the re-creating. Generally, the LFSCK can get the file's type from the name entry. Unfortunately, when we insert the name entry to the directory via dt_insert(), the sponsor does not transfer the file's type. It is not a problem for local case, because the OSD can get the file's type internally via checking the MDT-object directly. But for remote case, when the OSD handle the local insert, it cannot know the remote object's type. In DNE phase I, we only support remote directory, so the OSD can assume that the file's type is S_IFDIR. But such assumption will be wrong when enable remote object for normal file. |
| Comments |
| Comment by Andreas Dilger [ 26/May/14 ] |
|
Should this be fixed for 2.6 or is it part of DNE2 async commits for 2.7? |
| Comment by nasf (Inactive) [ 26/May/14 ] |
|
It is not related with async commit, but since there has already been DNE 1 released before, it is enough to land it to Lustre-2.7, instead of blocking Lustre-2.6. |
| Comment by nasf (Inactive) [ 26/May/14 ] |
|
Here is the patch: |
| Comment by Andreas Dilger [ 17/Jun/14 ] |
|
Since this is changing the OUT protocol I'd like to get the patch landed for 2.6.0 if possible. |
| Comment by nasf (Inactive) [ 09/Jul/14 ] |
|
The patch has been landed to master |