Data-on-MDT phase II (LU-10176)

[LU-10665] DoM: append to file causes OST component initialization Created: 14/Feb/18  Updated: 07/Apr/20  Resolved: 09/Mar/18

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Technical task Priority: Major
Reporter: Mikhail Pershin Assignee: Mikhail Pershin
Resolution: Duplicate Votes: 0
Labels: DoM2

Issue Links:
Duplicate
duplicates LU-9341 PFL: append should not instantiate fu... Resolved
Related
is related to LU-13420 append to PFL-file without 'eof' comp... Open
Rank (Obsolete): 9223372036854775807

 Description   

Append test for DoM files shows bad results after some changes in LOV/LOD. It causes OST component initialization with OST objects creation. That has bad effect on append itself but also makes impossible other optimizations for DoM file even when its size is still small.

DOM files append:

## ./smalliomany -a /mnt/lustre/dp_dom/file- 16384 300 
## 2018-01-28 19:04:36: START
total: append 33758741 bytes in 94 seconds: 359135.54 bytes/second
----- MDC RPCs: 163800
----- OSC RPCs: 16392 <--- that is wrong behavior


 Comments   
Comment by Mikhail Pershin [ 06/Mar/18 ]

this issue affects any file with PFL layout but hurts DOM files more than other, the problem with append is a range which is set to [0, EOF) and LOV
start initializing all components in the range even when append size is very small. To use correct range the file size is needed but it can be trusted only when lock is taken which is done after IO initialization. One possible way to fix this for PFL files is to use only last initialized component end as append end and restart IO if needed later (when file size is known, we have real range and it is clear that next component must be initialized).

Comment by Andreas Dilger [ 09/Mar/18 ]

This may be fixed by patch https://review.whamcloud.com/31411 "LU-9341 llite: don't instantiate full layout on append", which is a general problem for composite files, not just DoM.

Generated at Sat Feb 10 02:37:07 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.