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-12051 Lustre <p>Shrinking directories in ldiskfs would be desirable for cases where a directory had a large number of files created, but the files are deleted and the directory is empty and could be deallocated.</p> <p>There is a patch submitted to upstream ext4 that is the start of the support for this functionality, but it is not very aggressive about removing directory blocks: <a href="https://patchwork.ozlabs.org/patch/1048658/" class="external-link" target="_blank" rel="nofollow noopener">https://patchwork.ozlabs.org/patch/1048658/</a></p> <p>There is intended to be additional work in this area to improve the directory shrinking functionality.</p> <p>In addition to the directory shrinking, removal of old OST object directory trees (<tt>O/&#42;/d&#42;</tt>) is also useful, and could potentially be a substitute for having online directory shrink once the directories are completely empty.</p> LU-12051

ldiskfs directory shrink

Improvement Minor Open Unresolved WC Triage Andreas Dilger ldiskfs Thu, 7 Mar 2019 23:57:22 +0000 Mon, 23 Oct 2023 23:59:58 +0000 Lustre 2.12.0 0 6 <p>I suspect that there isn't a lot of work we <em>need</em> to do in this area, but some review and testing of the upstream patch linked in the description (with feedback directly to <tt>linux-ext4@kernel.vger.org</tt> and the author) would probably speed things up. After the code is landed upstream, or is at least showing good benefits and is robust, we could backport it to <tt>ldiskfs/kernel_patches</tt> for use until we catch up with a newer kernel.</p> <p>The upstream ext4 directory shrink patches have been refreshed:</p> <ul class="alternate" type="square"> <li><a href="https://patchwork.ozlabs.org/patch/1267257/" class="external-link" target="_blank" rel="nofollow noopener">PATCH v2,1/3 ext4: return lblk from ext4_find_entry</a></li> <li><a href="https://patchwork.ozlabs.org/patch/1267259/" class="external-link" target="_blank" rel="nofollow noopener">PATCH v2,2/3 ext4: shrink directories on dentry delete</a></li> <li><a href="https://patchwork.ozlabs.org/patch/1267258/" class="external-link" target="_blank" rel="nofollow noopener">PATCH v2,3/3 ext4: reimplement ext4_empty_dir() using is_dirent_block_empty</a></li> </ul> <p>The most complexity will be around integration of the "<tt>shrink directories on dentry delete</tt>" patches with the <tt>ext4-pdirop.patch</tt> patch, especially related to locking order as levels of the htree are removed. We will also need to disable the htree <tt>dx_root</tt> removal in <tt>make_unindexed()</tt> in the same way we do for <tt>ext4_update_dx_flag()</tt> because this would break htree locking and is of marginal benefit. At the point where all objects in a {<tt>SEQ}/d&#42;/</tt> directory tree have been removed on an OST, we can just delete the whole sequence directory tree rather than worry about the few remaining blocks for <tt>dx_root</tt>.</p> <p>These will mostly only shrink the directory when it is almost completely empty, but for <a href="https://jira.whamcloud.com/browse/LU-11912" title="reduce number of OST objects created per MDS Sequence" class="issue-link" data-issue-key="LU-11912"><del>LU-11912</del></a> this would still help reduce space usage as old objects are removed. There still needs to be a patch that merges adjacent htree blocks when they are nearly empty. My proposal for a possible implementation for htree leaf block merging was in <a href="https://lore.kernel.org/linux-ext4/04F44879-15DE-42EE-B87A-0690E9B13BB2@dilger.ca/" class="external-link" target="_blank" rel="nofollow noopener">this linux-ext4 thread</a> on an earlier version of the patch:</p> <blockquote> <p>On Mar 25, 2020, at 3:37 AM, Harshad Shirwadkar &lt;harshadshirwadkar@gmail.com&gt; wrote:<br/> &gt; But note that most of the shrinking happens during last 1-2% deletions<br/> &gt; in an average case. Therefore, the next step here is to merge dx nodes<br/> &gt; when possible. That can be achieved by storing the fullness index in<br/> &gt; htree nodes. But that's an on-disk format change. We can instead build<br/> &gt; on tooling added by this patch to perform reverse lookup on a dx<br/> &gt; node and then reading adjacent nodes to check their fullness.</p> <p>As for storing the fullness on disk changing the on-disk format... That is<br/> true, but the original htree implementation anticipated this and reserved<br/> space in the htree index to store the fullness, so it would not break the<br/> ability of older kernels to access directories with the fullness information.</p> <p>I think if you used just a few bits (maybe just 2) to store:<br/> 0 = unset (every directory today)<br/> 1 = under 20% full<br/> 2 = under 40% full<br/> 3 = under 60% full</p> <p>or similar. It doesn't matter if they are more full since they won't be<br/> candidates for merging, and then lazily update the htree index fullness<br/> as entries are removed, this will simplify the shrinking process, and will<br/> avoid the need to repeatedly scan the leaf blocks to see if they are empty<br/> enough for merging. It wouldn't be any worse <b>not</b> to store these values<br/> on disk after the first time a "0 = unset" entry was found and not merged,<br/> or setting the fullness on the merged block if it is merged, and running<br/> "e2fsck -D" can easily update the fullness values.</p> <p>The benefit of using 20%, 40%, and 60% as the fullness markers is that it<br/> is possible to either merge adjacent 60% and 40% blocks or alternately a<br/> 60% and two adjacent 20% blocks. Also, since these values are very coarse<br/> they would not need to be updated frequently. If the values are slightly<br/> outdated, then it is again not worse than the "always scan" model (one scan<br/> and the fullness would be updated), but more efficient than repeat scanning.</p> <p>Using only two bits for fullness also leaves two bits free for future use.</p></blockquote> Related LU-11912 LU-8465 Development Rank 1|i00cx3: Rank (Obsolete) 9223372036854775807