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-15686 Lustre <p>Dear WC Team,</p> <p>To mitigate <b>high cost of calling ftruncate on ZFS Lustre</b> (call used by fortran programs to extend the file size by certain chunk) - we are using localy mounted loop devices from Lustre.</p> <p>Underlying file is created as a sparse file, initialized as journal-less ext4 with lazy_itable_init=1,stride=32,stripe-width=256 parameters and mounted as temporary job storage.</p> <p>This solution works well with LDISKFS based OST. In the ZFS environment we are seeing a lots of op not supported errors:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[1118332.841747] blk_update_request: operation not supported error, dev loop0, sector 457191680 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0 [1118349.509300] blk_update_request: operation not supported error, dev loop0, sector 457195776 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0 </pre> </div></div> <p>Except of significant amount of logs we haven't seen application instability so far.</p> <p>This happens regardless of nodiscard,discard mount flags</p> <p> </p> <p> </p> Lustre 2.15.0RC2 + ZFS 2.0.7 <br/> LU-15686

loopdev: op 0x9:(WRITE_ZEROES) not supported on Lustre / ZFS

Bug Minor Open Unresolved WC Triage Lukasz Flis e2fsprogs Thu, 24 Mar 2022 10:30:27 +0000 Fri, 25 Mar 2022 14:08:34 +0000 0 2 <p>One clarification:  problem didn't appear on LDISKFS on 2.12 (there were no ll_fallocate function in 2.12)</p> <p>The problem is likely to be  present in LDISKFS and 2.15 as well</p> <p>The "discard" mount option for ext4 is not recommended to be used, as it causes a significant performance overhead.</p> <p>As for the errors appearing even without "-o discard", is it possible that the errors are generated during mkfs time? Running newer mke2fs will try to trim the whole device to free flash erase blocks and thin-provisioned storage, and use "write same" to avoid explicitly zeroing the inode table. However, if "lazy_itable_init" is used, then the itable zeroing is deferred to a kernel thread that also tries to zero the inode table blocks with "write same" after the filesystem is mounted.</p> <p>There is an experimental patch to mke2fs that will assume the whole filesystem is "zeroed", which can be used for the case of loopback devices that are on <b>newly created</b> sparse files that are known to contain only zeroes:<br/> <a href="https://patchwork.ozlabs.org/project/linux-ext4/patch/20210921034203.323950-1-sarthakkukreti@google.com/" class="external-link" target="_blank" rel="nofollow noopener">https://patchwork.ozlabs.org/project/linux-ext4/patch/20210921034203.323950-1-sarthakkukreti@google.com/</a></p> <p>This patch is included in upstream e2fsprogs v1.46.5, but not yet in the Lustre e2fsprogs-1.46.2-wc4. We have never tested the <tt>assume_storage_prezeroed</tt> function, but if this version is only being used on the client against a loopback file, and not on the server, it shouldn't cause any problems. </p> <p>Hi Andreas,</p> <p>During mount we are supplying -o nodiscard flag which seems to be effective, i.e:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[Wed Mar 23 14:24:57 2022] EXT4-fs (loop0): mounted filesystem without journal. Opts: nodiscard </pre> </div></div> <p>I am sure that (looking at the logs where ) the <b>op not supported</b>  errors appear <b>after</b> mkfs is completed and fs mounted. This seems to be an effect of using loopmounted ext4 fs.</p> <p> </p> Related LU-15607 Development Rank 1|i02llr: Rank (Obsolete) 9223372036854775807 Severity