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-8210 Lustre <p>sanity:156 test failed in rhel7 plataform for writecache disable<br/> and readcache enabled.</p> <p>12288 bytes (12 kB) copied, 0.00750388 s, 1.6 MB/s<br/> cache hits:: before: 4142, after: 4142<br/> Read again; it should be satisfied from the cache.<br/> sanity test_156: @@@@@@ FAIL: NOT IN CACHE: before: 4142, after: 4142 <br/> Trace dump:<br/> = /usr/lib64/lustre/tests/test-framework.sh:4730:error_noexit()<br/> = /usr/lib64/lustre/tests/test-framework.sh:4761:error()<br/> = /usr/lib64/lustre/tests/sanity.sh:10271:test_156()<br/> = /usr/lib64/lustre/tests/test-framework.sh:5008:run_one()<br/> = /usr/lib64/lustre/tests/test-framework.sh:5045:run_one_logged()<br/> = /usr/lib64/lustre/tests/test-framework.sh:4910:run_test()<br/> = /usr/lib64/lustre/tests/sanity.sh:10278:main()</p> LU-8210

OST Read Cache does not work in Centos7 platform

Bug Major Resolved Fixed Yang Sheng Wang Shilong patch Fri, 27 May 2016 14:04:48 +0000 Thu, 14 Jun 2018 21:41:16 +0000 Thu, 2 Jun 2016 11:49:08 +0000 Lustre 2.9.0 Lustre 2.9.0 0 8 <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="http://review.whamcloud.com/20478" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20478</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8210" title="OST Read Cache does not work in Centos7 platform" class="issue-link" data-issue-key="LU-8210"><del>LU-8210</del></a> osd-ldiskfs: fix setting pages PageUptodate state<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: f8630c9a585c97550405fa5cbb9f0d48ff4a37c8</p> <p>Intresting thing is that we should always reproduce this problem in rhel7 platform, but I don't see<br/> it reproduced in Intel autotest platform, but we could reproduce it in our environment.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>53 * drivers should _never_ use the all version - the bio may have been split 154 * before it got to the driver and the driver won't own all of it 155 */ 156 #define bio_for_each_segment_all(bvl, bio, i) \ 157 for (i = 0; \ 158 bvl = bio_iovec_idx((bio), (i)), i &lt; (bio)-&gt;bi_vcnt; \ 159 i++) 160 161 #define bio_for_each_segment(bvl, bio, i) \ 162 for (i = (bio)-&gt;bi_idx; \ 163 bvl = bio_iovec_idx((bio), (i)), i &lt; (bio)-&gt;bi_vcnt; \ 164 i++) Here is difference between two interface, bio_for_each_segment_all() start from index,0 while bio_for_each_segment start from @bi_idx, while @bi_idx might change in bio_advance() during IO handling. Aslo Looking from How Current upstream Filesystem handle page state updates in end IO: [root@server11 fs]# git grep bio_for_each_segment_all btrfs/compression.c: bio_for_each_segment_all(bvec, cb-&gt;orig_bio, i) btrfs/disk-io.c: bio_for_each_segment_all(bvec, bio, i) { btrfs/extent_io.c: bio_for_each_segment_all(bvec, bio, i) { btrfs/extent_io.c: bio_for_each_segment_all(bvec, bio, i) { btrfs/extent_io.c: bio_for_each_segment_all(bvec, bio, i) { btrfs/inode.c: bio_for_each_segment_all(bvec, bio, i) btrfs/inode.c: bio_for_each_segment_all(bvec, &amp;io_bio-&gt;bio, i) { btrfs/inode.c: bio_for_each_segment_all(bvec, bio, i) { btrfs/inode.c: bio_for_each_segment_all(bvec, &amp;io_bio-&gt;bio, i) { crypto/crypto.c: bio_for_each_segment_all(bv, bio, i) { direct-io.c: bio_for_each_segment_all(bvec, bio, i) { exofs/ore.c: bio_for_each_segment_all(bv, bio, i) { exofs/ore_raid.c: bio_for_each_segment_all(bv, bio, i) { ext4/page-io.c: bio_for_each_segment_all(bvec, bio, i) { ext4/readpage.c: bio_for_each_segment_all(bv, bio, i) { ext4/readpage.c: bio_for_each_segment_all(bv, bio, i) { f2fs/data.c: bio_for_each_segment_all(bvec, bio, i) { f2fs/data.c: bio_for_each_segment_all(bvec, bio, i) { f2fs/data.c: bio_for_each_segment_all(bvec, io-&gt;bio, i) { gfs2/lops.c: bio_for_each_segment_all(bvec, bio, i) { gfs2/meta_io.c: bio_for_each_segment_all(bvec, bio, i) { logfs/dev_bdev.c: bio_for_each_segment_all(bvec, bio, i) { mpage.c: bio_for_each_segment_all(bv, bio, i) { </pre> </div></div> <p>I am still wondering why Intel autotest could pass this test, maybe I miss something here...........</p> <p>I see from Documentation/block/biodoc.txt </p> <ul class="alternate" type="square"> <li>Drivers which can't process a large bio in one shot can use the bi_idx<br/> 484 field to keep track of the next bio_vec entry to process.<br/> 485 (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)<br/> 486 [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying<br/> 487 bi_offset an len fields]</li> </ul> <p>So this problem might be related to Specific Driver which can explain<br/> why we could reproduce it in our environment, however, we still need fix this issue<br/> In Lustre.</p> <p>Yang Sheng</p> <p>Could you please advise on this issue?</p> <p>Thanks</p> <p>Peter</p> <p>Hi, Wang,</p> <p>Do you mind provide which type disk driver apply in your test environment. I am interesting to do a reproduction.</p> <p>Thanks,<br/> YangSheng</p> <p>Hi Sheng,</p> <p> Qemu configurations something like this:</p> <p> &lt;disk type='file' device='disk'&gt;<br/> &lt;driver name='qemu' type='qcow2' cache='none'/&gt;<br/> &lt;source file='/home/vms/autotest-el7.2-vm5b.img'/&gt;<br/> &lt;target dev='sdb' bus='virtio'/&gt;<br/> &lt;address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/&gt;<br/> &lt;/disk&gt;</p> <p>Regards,<br/> Shilong</p> <p>Many thanks for your help.</p> <p>Thanks,<br/> YangSheng</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/20478/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20478/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8210" title="OST Read Cache does not work in Centos7 platform" class="issue-link" data-issue-key="LU-8210"><del>LU-8210</del></a> osd-ldiskfs: fix setting pages PageUptodate state<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 5e5e4ae2be4bc377f0f896163ae59bf338c4250c</p> <p>Landed for 2.9</p> <p>This patch breaks support with the latest kernels <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> Is the lloop driver that breaks.</p> <p>Luckily I thought we are deleting lloop, so that would be the easiest fix?</p> <p>The default loop doesn't support direct I/O until the 4.6 kernel if I remember right. So we still need the fix for kernels between 3.16 &lt;-&gt; 4.5</p> Duplicate Related LU-8056 Development Rank 1|hzycyv: Rank (Obsolete) 9223372036854775807 Severity