https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-17371 Lustre <p>The OFD access log reader generates records for files that were <b>just</b> created and are being written for the first time.</p> <p>This can be confusing in the case of background filesystem maintenance operations, such as "<tt>lfs mirror &#42;</tt>", "<tt>lfs migrate</tt>", and "<tt>lfs hsm &#42;</tt>" operations that incorrectly give the impression that the file is under active application usage when it is not.</p> <p>There should be a mechanism under which these background maintenance operations do not inflate the heat of files.</p> LU-17371

OFD ALR records should not be generated for maintenance operations

Improvement Minor Open Unresolved WC Triage Andreas Dilger Fri, 15 Dec 2023 20:20:28 +0000 Fri, 15 Dec 2023 21:26:39 +0000 Lustre 2.14.0 Lustre 2.16.0 0 3 <p>One relatively simple solution would be to have a "quiet time" for newly created objects, so that writes during this initial period do not generate ALR records and do not count as "heat" for the file. Something like "<tt>obdfilter.&#42;.access_log_quiet=300</tt>" set on the OSTs would skip ALR generation for the first 300s after the object is created. This could be used to differentiate </p> <p>This would cover the <b>write</b> cases for "<tt>lfs mirror extend</tt>" and "<tt>lfs migrate</tt>" and "<tt>lfs hsm restore</tt>" where new OST objects are allocated for the file, or other tools that may be creating and writing files directly in a "cold" OST pool.</p> <p>It would <b>not</b> cover the case for "<tt>lfs mirror resync</tt>" where writes are done to an existing object, nor the <b>read</b> traffic generated by "<tt>lfs mirror extend</tt>", "<tt>lfs mirror resync</tt>", "<tt>lfs migrate</tt>", or "<tt>lfs hsm archive</tt>". In order to handle this case, there should be an interface (maybe llapi_ladvise(LU_LADVISE_NOALR)}}") that can set a flag on the file descriptor that will flag all <tt>OBD_BRW</tt> RPCs so that they do not generate ALR records. This is somewhat overlapping with the <tt>access_log_quiet</tt> functionality, but that has the benefit that it can be applied to old clients/utilities that are not able to use <tt>LU_LADVISE_NOALR</tt>.</p> Related Development Rank 1|i04553: Rank (Obsolete) 9223372036854775807 Severity