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-10370 Lustre <p>Running <tt>truncate --size=N file</tt> on a file larger than {{N} will correctly update and return the file size to the client, but does not update the client's idea of the block count. Running the following test fails on my 2.10.1 system:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ dd if=1k bs=1M /myth/tmp/largefile $ truncate --size 512M /myth/tmp/largefile </pre> </div></div> <p>The size is updated on the client to 512MB, but the blocks are left at 1GB in the client cache.</p> LU-10370

"truncate" does not update blocks count on client

Bug Minor Resolved Fixed Arshad Hussain Andreas Dilger patch Tue, 12 Dec 2017 09:09:41 +0000 Wed, 13 Feb 2019 04:32:33 +0000 Tue, 19 Jun 2018 20:14:37 +0000 Lustre 2.10.1 Lustre 2.12.0 0 10 <p>The OSS should be replying with the object attributes (blocks, size, timestamps) from the truncate, and these should be updating the client's cached state.</p> <p>Hi Andreas,</p> <p>Will osc_io.c:osc_cache_truncate_end() be the correct place to add the changes. What should be the correct approach for this fix. Could you help out here with the correct approach to follow for this? I can have a look at this one and then adapt the same for fallocate.</p> <p>Thanks</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Dec 18 09:48:10 mrpel7 kernel: Call Trace: Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff81633ec4&gt;] dump_stack+0x19/0x1b Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0aa5a55&gt;] osc_cache_truncate_end+0x6d5/0xc10 [osc] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa08a0bac&gt;] ? ptlrpc_request_bufs_pack+0x1ec/0x480 [ptlrpc] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0a96272&gt;] ? osc_page_gang_lookup+0x272/0x320 [osc] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0a90400&gt;] ? osc_io_data_version_end+0x190/0x190 [osc] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0a8ffe2&gt;] osc_io_setattr_end+0x162/0x1b0 [osc] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0b1b480&gt;] ? lov_io_iter_fini_wrapper+0x50/0x50 [lov] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa068b8fd&gt;] cl_io_end+0x5d/0x150 [obdclass] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0b1b55b&gt;] lov_io_end_wrapper+0xdb/0xe0 [lov] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0b1bbb5&gt;] lov_io_call.isra.5+0x85/0x140 [lov] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa0b1bca6&gt;] lov_io_end+0x36/0xb0 [lov] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa068b8fd&gt;] cl_io_end+0x5d/0x150 [obdclass] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa068df8f&gt;] cl_io_loop+0x13f/0xc70 [obdclass] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa10ea870&gt;] cl_setattr_ost+0x280/0x3d0 [lustre] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa10c4ea5&gt;] ll_setattr_raw+0x1165/0x1270 [lustre] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffffa10c501c&gt;] ll_setattr+0x6c/0xd0 [lustre] Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff811fb6b9&gt;] notify_change+0x279/0x3d0 Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff811dc7a3&gt;] do_truncate+0x73/0xc0 Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff811e1038&gt;] ? __sb_start_write+0x58/0x110 Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff811dcb4c&gt;] do_sys_ftruncate.constprop.17+0x11c/0x180 Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff811dcbee&gt;] SyS_ftruncate+0xe/0x10 Dec 18 09:48:10 mrpel7 kernel: [&lt;ffffffff816448c9&gt;] system_call_fastpath+0x16/0x1b </pre> </div></div> <p>Jinshan or Bobijam,<br/> can you please comment on the best approach for this. The client should have the blocks count updated by the reply from <tt>OST_PUNCH</tt>, since it will currently keep the old (pre-truncate) blocks count in cache until the DLM lock is cancelled, which may be an hour or more.</p> <p>This may also be a problem for LSOM, since the client's update of the LSOM state on the MDT will not be correct after a truncate if it is caching the wrong data.</p> <p>Arshad Hussain (arshad.super@gmail.com) uploaded a new patch: <a href="https://review.whamcloud.com/31073" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/31073</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10370" title="&quot;truncate&quot; does not update blocks count on client" class="issue-link" data-issue-key="LU-10370"><del>LU-10370</del></a> osc: truncate does not update blocks count on client<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 4b5055a464d1b2d190d5b7f49f68f7e4a60653c6</p> <p>Hi Andreas,</p> <p>Debugging OST_PUNCH found that server does not reply back with updated blocks count to client. Presently OST_PUNCH RPC is processed under lustretre/ofd/ofd_dev.c:ofd_punch_hdl(). Here server does not update repbody with updated block count.</p> <p>Addressing this allows the client to fetch these values in RPC reply. Under osc_io.c:osc_io_setattr_end() I could update object attributes with updated values received from server calling cl_object_attr_update(). Ive added tests to verify truncate reflects block count correctly for sparse files as well. </p> <p>We can format and push a patch for review if this looks like a good solution. </p> <p>The output of truncate run on Sparse file:<br/> ===============================</p> <ol> <li>yes 'a' | dd of=/mnt/lustre/sparstest bs=4096 count=2 seek=5<br/> 2+0 records in<br/> 2+0 records out<br/> 8192 bytes (8.2 kB) copied, 0.001071 s, 7.6 MB/s</li> </ol> <ol> <li>stat /mnt/lustre/sparstest<br/>   File: '/mnt/lustre/sparstest'<br/>   Size: 28672           Blocks: 16         IO Block: 4194304 regular file<br/> Device: 2c54f966h/743766374d    Inode: 144115205272502281  Links: 1<br/> Access: (0644/<del>rw-r</del><del>r</del>-)  Uid: (    0/    root)   Gid: (    0/    root)<br/> Access: 2018-02-08 18:24:18.000000000 +0530<br/> Modify: 2018-02-08 18:24:18.000000000 +0530<br/> Change: 2018-02-08 18:24:18.000000000 +0530<br/>  Birth: -</li> </ol> <ol> <li>truncate -s24500 /mnt/lustre/sparstest</li> </ol> <ol> <li>stat /mnt/lustre/sparstest<br/>   File: '/mnt/lustre/sparstest'<br/>   Size: 24500           Blocks: 8          IO Block: 4194304 regular file<br/> Device: 2c54f966h/743766374d    Inode: 144115205272502281  Links: 1<br/> Access: (0644/<del>rw-r</del><del>r</del>-)  Uid: (    0/    root)   Gid: (    0/    root)<br/> Access: 2018-02-08 18:24:18.000000000 +0530<br/> Modify: 2018-02-08 18:24:42.000000000 +0530<br/> Change: 2018-02-08 18:24:42.000000000 +0530<br/>  Birth: -</li> </ol> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/31073/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/31073/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10370" title="&quot;truncate&quot; does not update blocks count on client" class="issue-link" data-issue-key="LU-10370"><del>LU-10370</del></a> ofd: truncate does not update blocks count on client<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 6115eb7fd55abca12c110535be4f777e3eba2b10</p> <p>Landed for 2.12</p> <p> </p> Related LU-3606 LU-9538 LU-11778 Development Rank 1|hzzp6v: Rank (Obsolete) 9223372036854775807 Severity