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-11379 Lustre <ol> <li>Flatten archive hierarchy to 1 directory. <tt>/arc1/0001/0000/0401/0000/0002/0000/0x200000401:0x1:0x0</tt> becomes <tt>/arc1/0001/0x200000401:0x1:0x0</tt>.</li> <li>Remove/deprecate shadow tree handling.</li> <li>Stop storing and loading <tt>_lov</tt> files. For restore, we are already getting file attributes+striping from the MDT (see <tt>ct_md_getattr()</tt>). But we only use the stat portion of the lmd.</li> <li>Improve thread handling.</li> </ol> LU-11379

HSM Copytool Performance Improvements

Bug Minor Closed Fixed WC Triage John Hammond HSM Fri, 14 Sep 2018 19:35:17 +0000 Wed, 14 Jul 2021 11:53:53 +0000 Wed, 14 Jul 2021 11:53:53 +0000 0 3 <blockquote> <p>1. Flatten archive hierarchy to 1 directory. <tt>/arc1/0001/0000/0401/0000/0002/0000/0x200000401:0x1:0x0</tt> becomes <tt>/arc1/0001/0x200000401:0x1:0x0</tt>.</p></blockquote> <p>Presumably the "0001" is based on <tt>OID % 0xffff</tt>? Is there a desire to have some temporal locality with objects in the archive, rather than all 65k directories being used continually?</p> <p>One drawback of using the same directories forever is that they get relatively large and fragmented in the hash space, and are updated totally randomly on disk. For MDS-&gt;OST object allocation, I've thought about using something like <tt>SEQ&gt;&gt;8/OID&gt;&gt;16</tt> or just stick with <tt>SEQ/d(OID % 32)</tt> but limit OIDs-per-SEQ to 1M or so, which will put concurrently allocated objects relatively close together, but slowly move into new upper-level directories over time. The premise is that concurrently allocated objects are more likely to also be accessed and deleted together, so we can slowly drop those older directories from RAM, and eventually shrink them down as they become empty. Having a single huge directory with all ages of files means the whole directory needs to live in RAM, or be IOPS bound during modification since each insert/delete/lookup will modify a different leaf block.</p> <blockquote> <p>3. Stop storing and loading <tt>&#95;lov</tt> files. For restore, we are already getting file attributes+striping from the MDT (see <tt>ct_md_getattr()</tt>). But we only use the stat portion of the lmd.</p></blockquote> <p>One reason for storing the LOV EA in the archive is for disaster recovery/rehydrate. If we instead make full backups of the MDT(s) and/or subtrees, then we don't need the layouts or other xattrs in the archive. Conversely, storing xattrs (more than just <tt>lov</tt>) with the files makes them more "self contained" and usable even if the MDT backup is unavailable.</p> <p>PS - you are unlikely to get even OID distribution across <span class="error">&#91;0x0000-0xffff&#93;</span>. It is much more likely to get low-numbered OIDs, since clients always start with a new SEQ after mount and will allocate an OID=1 file, but won't necessarily allocate OID=65535 or OID=131071 ever before restart. That will put more pressure on the low-numbered directories and may cause problems in some archives.</p> <p>&gt; One reason for storing the LOV EA in the archive is for disaster recovery/rehydrate. If we instead make full backups of the MDT(s) and/or subtrees, then we don't need the layouts or other xattrs in the archive. Conversely, storing xattrs (more than just lov) with the files makes them more "self contained" and usable even if the MDT backup is unavailable.</p> <p>HSM (alone) is not a disaster recovery solution. It's a storage tiering mechanism. It LOV is important then either keep full MDT images or store copies of LOV in the policy tool DB.</p> <p>A partial patch for this was pushed for review under <a href="https://jira.whamcloud.com/browse/LU-11380" title="IOC_MDC_GETFILEINFO returns garbage stripe info for files with long names but no striping" class="issue-link" data-issue-key="LU-11380"><del>LU-11380</del></a>. See <a href="https://review.whamcloud.com/#/c/33215/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/33215/</a>. </p> <p><a href="https://jira.whamcloud.com/browse/LU-11380" title="IOC_MDC_GETFILEINFO returns garbage stripe info for files with long names but no striping" class="issue-link" data-issue-key="LU-11380"><del>LU-11380</del></a> hsm: streamline copytool restore handling</p> <p>Partial patch.</p> <p>Signed-off-by: John L. Hammond &lt;jhammond@whamcloud.com&gt;<br/> Change-Id: I7435766f6f67ba60ac39bf02bc3232316a830387</p> <p>Archive flattening is in progress under LU-144359. </p> <p><a href="https://review.whamcloud.com/41312" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41312</a> <a href="https://jira.whamcloud.com/browse/LU-14359" title="support a flat HSM archive format" class="issue-link" data-issue-key="LU-14359">LU-14359</a> hsm: support a flatter HSM archive format<br/> <a href="https://review.whamcloud.com/41366" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41366</a> <a href="https://jira.whamcloud.com/browse/LU-14359" title="support a flat HSM archive format" class="issue-link" data-issue-key="LU-14359">LU-14359</a> hsm: support shadow tree in archive upgrade</p> <p>Partially fixed. Partially abandoned.</p> Related LU-11380 Development Rank 1|i002hj: Rank (Obsolete) 9223372036854775807 Severity