[LU-2399] create objects on truncate

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0
• Fix Version/s: Lustre 2.10.0
• Type: Improvement
• Priority: Major
• Reporter: Alex Zhuravlev
• Assignee: John Hammond
• Resolution: Fixed
• Epic/Theme: ORI-4
• Story Points: 3

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.

Issue Links

• duplicates: LU-2808 osp_object_assign_fid()) ASSERTION( f...

Comments

[Mikhail Pershin]

ticket was solved and landed, wasn't it?

[Andreas Dilger]

Alex, was this fixed in master?

[Andreas Dilger]

Alex, was this fixed when LOD landed to master?

[Alex Zhuravlev]

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.

[Johann Lombardi (Inactive)]

TBH, i tend to think we can get rid off this code. Jinshan?

[Jinshan Xiong (Inactive)]

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.

[Alex Zhuravlev]

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 Lombardi (Inactive)]

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.

[Alex Zhuravlev]

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.

[Andreas Dilger]

Prototype patch in http://review.whamcloud.com/5473

[Andreas Dilger]

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).

[Zhenyu Xu]

Yes, truncate now will create enough OST objects to cover the file size .