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-16920 Lustre <p>In order to allow device-level scanners to detect compressed OST objects (and to a lesser extent compressed MDT DoM objects) during scanning, it makes sense to store a flag on each OST object that is storing compressed data. This will allow the scanner to identify compressed objects, for example to compute the compression ratio during an OST-levels scan, and/or implement other policies during scanning without having the full file layout.</p> <p>While there is an existing <tt>EXT4_COMPR_FL</tt> that could be stored on the ldiskfs inode for this purpose, it may have adverse interactions with ext4 or e2fsck now or in the future, if ext4-level compression is ever implemented.</p> <p>Instead, we should store the compressed object state with <tt>LMAC_COMPRESSED=0x00000080</tt> in the <tt>trusted.lma</tt> xattr on each object. I don't believe that the storage of compressed objects should need an <tt>LMAI_COMPRESSED</tt> (incompatible) flag, since there is nothing on the OST that needs to be aware of this state during a read, since the decompression is handled entirely on the client.</p> <p>The OST would be informed by the client about the presence of compressed data with the <tt>OBD_BRW_COMPRESSED</tt> flag added in patch <a href="https://review.whamcloud.com/50154" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/50154</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-16603" title="OBD_BRW_COMPRESSED flag" class="issue-link" data-issue-key="LU-16603"><del>LU-16603</del></a> protocol: add OBD_BRW_COMPRESSED</tt>".</p> <p>Other than saving the flag on the OST object one time, there is no other action required by the OST in this case.</p> <p>For non-DoM files, the MDT will not see the <tt>OBD_BRW_COMPRESSED</tt> flag. The MDS could set the <tt>LMAC_COMPRESSED</tt> flag in <tt>trusted.xattr</tt> as soon as a compressed component is instantiated.</p> <p>The MDS should report the <tt>LMAC_COMPRESSED</tt> flag in the inode flags as <tt>LUSTRE_COMPR_FL=FS_COMPR_FL=0x00000004</tt>, similar to <tt>LUSTRE_ENCRYPT_FL</tt>, so that the compression state can be displayed on the client via <tt>lsattr</tt>. It should report <tt>STATX_ATTR_COMPRESSED=0x00000004</tt> via <tt>statx()</tt>, similar to <tt>STATX_ATTR_ENCRYPTED</tt>.</p> LU-16920

CSDC: store and report compression flag on OST and MDT objects

Improvement Major Open Unresolved Zhenyu Xu Andreas Dilger csdc Wed, 21 Jun 2023 19:39:02 +0000 Mon, 22 Jan 2024 15:55:34 +0000 Lustre 2.16.0 0 3 <p>Andreas,</p> <p>Hmm.  If we're going to store "compressed or not" in the server side objects, would it be reasonable to also store the compression chunk size?  I understand if space usage or other concerns dominate, but this would make it possible for the server to round lock grants to chunk size.  This comes up specifically for locks the server is extending, where the server controls the lock boundary that results.</p> <p>It's a relatively small case - in practice, we'll have the clients rounding their dlmlock requests to chunk size boundaries, and that should (again, in practice) result in the server always ending up on chunk boundaries, even under contention.  (Because it is under contention that locks can end up at unusual sizes.  Without contention it doesn't happen.)</p> <p>But it would have a certain comfort factor for the server to only grant locks on chunk boundaries as well, which would be straightforward if the server also had the chunk bits.  (Technically only the OST objects would need this, since DOM locks are always full object, but...)</p> <p>Andreas pointed out elsewhere that we actually already round all LDLM lock grants to be aligned to the start/end of the lock as requested by the client.  This will ensure that all locks are chunk aligned as granted by the server.  Very nice.</p> <blockquote> <p>If we're going to store "compressed or not" in the server side objects, would it be reasonable to also store the compression chunk size? I understand if space usage or other concerns dominate, but this would make it possible for the server to round lock grants to chunk size.</p></blockquote> <p>Storing the compression chunk size on the OST objects would be desirable to help LFSCK reconstruct the LOV file layout in case it was corrupted/lost on the MDT. We already store other parts of the file layout on each OST object for this exact reason, so it makes sense to do the same for the compressed chunk size. However, this is not critical, since it would also be possible for LFSCK to read the first (or any) allocated chunk of a file to determine the chunk size used and other compression parameters, as long as it knows that this is a compressed file.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> #define LLCH_MAGIC 0xC0398E55DA7A <span class="code-comment">/* Compression chunk header */</span> struct ll_compr_hdr { __u64 llch_magic:48; <span class="code-comment">/* LLCH_MAGIC */</span> __u8 llch_header_size; <span class="code-comment">/* = 32, <span class="code-keyword">for</span> <span class="code-keyword">future</span> extensions */</span> __u8 llch_exta_flags; __u8 llch_compr_type; <span class="code-comment">/* LL_COMPR_TYPE_* */</span> __u8 llch_compr_level:4; <span class="code-comment">/* per-algorithm mapped level */</span> __u8 llch_flags:4; __u8 llch_chunk_log_bits; <span class="code-comment">/* log2(chunk_size) - 16 */</span> __u32 llch_compr_size; <span class="code-comment">/* bytes of compressed data */</span> __u32 llch_reserved; <span class="code-comment">/* unused, initialize to 0 */</span> __u32 llch_uncompr_csum; <span class="code-comment">/* crc32 of raw data, or 0 */</span> __u32 llch_compr_csum; <span class="code-comment">/* crc32 of compressed data, or 0 */</span> __u32 llch_hdr_csum; <span class="code-comment">/* crc32 of magic..compr_csum, or 0 */</span> }; </pre> </div></div> Duplicate Related LU-16603 Development Rank 1|i03olz: Rank (Obsolete) 9223372036854775807 Severity