[LU-7900] lu_object_assign_fid() doesn't need to lookup FID Created: 22/Mar/16 Updated: 01/Oct/16 Resolved: 13/Jul/16 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.9.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Alex Zhuravlev | Assignee: | Alex Zhuravlev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
lu_object_assign_fid() doesn't need to lookup FID as the FID is supposed to be unique. that lookup was to assert if something went wrong, but it never got hit in the end. it's time to remove that. |
| Comments |
| Comment by Andreas Dilger [ 22/Mar/16 ] |
|
Doesn't this depend on the correct operation of the client, which may be OK now, but could break in the future? I agree we don't want to do extra lookups, but our checking of FIDs is already very lax. At a minimum, we should catch duplicate FID usage when the FID is inserted into the OI? For example, we do not verify if a new FID from a client was actually from a SEQ allocated to that client at all. It would be useful to store the last FID SEQs allocated to the client in the export, or keep a global range of valid SEQs for that target (assigned from SEQ master, not more than largest SEQ assigned to client), so that it can verify the incoming FID is (relatively) valid with low effort. Otherwise, we can get into trouble if the client is spewing garbage FIDs, like the 1.8 big-endian clients that didn't swab their incoming SEQ assignments properly. See LU-4232 and LU-4233 for details. |
| Comment by Alex Zhuravlev [ 22/Mar/16 ] |
|
this one is used only for OST object being created during striping creation. |
| Comment by Gerrit Updater [ 23/Mar/16 ] |
|
Alex Zhuravlev (alexey.zhuravlev@intel.com) uploaded a new patch: http://review.whamcloud.com/19081 |
| Comment by Gerrit Updater [ 11/Jul/16 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/19081/ |
| Comment by Joseph Gmitter (Inactive) [ 13/Jul/16 ] |
|
Patch has landed to master for 2.9.0 |