Details
-
Improvement
-
Resolution: Fixed
-
Major
-
Lustre 2.4.0
-
None
-
3
-
2410
Description
OSP tries to address one issue found in LOV/OSC: objid is assigned outside of transaction and this can lead to gaps in objid sequence and leaked OST objects.
OSP does this assignment with transaction open. but there is one exception: truncate on a file with no objects created. if later we create OST objects (upon open for write), then MDS sends OST_PUNCH to propagate non-zero size to OST. but we can't do this holding open transaction. so we again have to assign
objid and send OST_PUNCH outside of transaction. this lead to leaked objects
(in case of server failure) and complications in the code.
so we have decided to avoid this situation: truncate will be creating OST objects, return newly created LOVEA back to the client and the client will
be doing regular truncate to OSTs propagating requested size.
essentially truncate becomes a form of open. this is especially true with
SOM, because truncate has to open an epoch. we may use this fact to re-use
some code on MDS to implement OST object creation on truncate.
Attachments
Issue Links
- duplicates
-
LU-2808 osp_object_assign_fid()) ASSERTION( fid_is_zero(lu_object_fid(&o->opo_obj.do_lu)) ) failed:
-
- Closed
-
Activity
The 5473 patch was abandoned, and does not implement the object create at file truncate time.
This feature would be quite useful for Data-on-MDT to allow applications to specify the file size at create time and then the MDS decides what layout to use based on the specified file size (DOM for files < 1MB, 1 or few stripes for files < 1GB, widely striped for larger files).
I'm fine with that. the sooner we have this done, the sooner we can fix this issue and drop very specific bits of the code.
Sure, but if you backport this change to 2.1 (1.8 should be fine, right?), then all configurations with 2.1, 1.8 and 2.4 clients (99% of the 2.4 installations?) won't suffer from the leak issue. There is already a client incompatibility issue with older versions due to EINPROGRESS support.
well, but it won't work with old clients, that's the point - originally we thought we create objects on truncate with no changes on the client side.
Johann, client code will be okay without that piece of code, however I don't know if it will affect SoM.
I tend to think it's okay after checking the code.
TBH, i tend to think we can get rid off this code. Jinshan?
sorry, meant to answer on the first question, but .. so I tried to implement this, but met a problem on the client. It was months ago,
but if I remember correctly the client does not issue OST_SETATTR if lsm was not set before MDS_REINT_SETATTR:
/* NB: ATTR_SIZE will only be set after this point if the size
- resides on the MDS, ie, this file has no objects. */
if (lsm != NULL)
attr->ia_valid &= ~ATTR_SIZE;
I wouldn't mind to change this though.
Yes, truncate now will create enough OST objects to cover the file size .