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-16588 Lustre <p>Working on patch <a href="https://review.whamcloud.com/50074" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/50074</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-16501" title="QOS allocator not balancing space enough" class="issue-link" data-issue-key="LU-16501"><del>LU-16501</del></a> lod: add qos_ost_weights to debugfs</tt>" I found that <tt>lod-&gt;lod_mdt_descs.ltd_tgt_pool</tt> doesn't include local MDT. I.e. in a single node setup with 2 MDTs lod mdt descriptor(lod_tgt_descs) for lustre-MDT0000-mdtlov includes only MDT0001, while lustre-MDT0001-mdtlov includes only tgt MDT0000. Is this correct from QOS point of view?</p> LU-16588

lod doesn't include local MDT

Story Minor Open Unresolved WC Triage Sergey Cheremencev Thu, 23 Feb 2023 17:23:40 +0000 Thu, 23 Feb 2023 20:57:30 +0000 0 4 <p>Well, since you can only have one stripe per MDT, the first stripe has already been picked by the time you are on the local MDT.  The local MDT is the first stripe.  So I think it's OK for QOS as long as you only have 1 stripe per MDT, because the local MDT isn't a valid choice.</p> <p>Of course, this causes problems for metadata overstriping (which is not complete yet):</p> <p>But I fixed them by special-casing the local MDT in QOS.<br/> See <a href="https://review.whamcloud.com/c/fs/lustre-release/+/35034/12/lustre/lod/lod_qos.c" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/35034/12/lustre/lod/lod_qos.c</a></p> <p>I didn't think it was realistic to add the local MDT to LOD - It seemed like too big of a change...?</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a> or <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=laisiyao" class="user-hover" rel="laisiyao">laisiyao</a> might have more to say about how QOS works today.</p> <p>It seems reasonable from a QOS point of view that the local MDT is also included in the QOS weighting, rather than <b>always</b> creating a stripe on the local MDT. Consider the common case where MDT0000 is more full than other MDTs (filesystem predating MDT mkdir balancing), then if a new striped directory is created on MDT0000 it will always have a local stripe. It would be better to only create the master stripe on the local MDT and all of the remote stripes on less-full remote MDTs. Of course it would be better if the master + stripes were <b>all</b> created on the remote MDTs, but this would still use an agent inode on MDT0000 so it isn't any more efficient.</p> <p>I don't think this is a fatal problem, but has come up at least twice now in different contexts, so may be worthwhile to fix. The LOD itself has a connection to the local MDT, but this is treated somewhat differently since it is a local OSD device rather than a remote OSP device. It might make sense to include the local MDT into the QOS tables without changing the connections (which I think would be complex and bad for performance), but it should still prioritize using the local MDT if it is within the reasonable usage of other MDTs, but skip it if the local MDTs is significantly overused.</p> <p>For the purpose of patch 50047 I think showing the current state of the QOS table without the local MDT is OK, since that reflects the actual reality of the implementation, and if/when the local MDT is added to the QOS table it should also appear in the QOS parameter output. </p> Duplicate Related LU-16501 Development Rank 1|i03evz: Rank (Obsolete) 9223372036854775807