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-684 Lustre <p>   #define BIO_RDONLY 31 /* device is readonly */<br/> #define BIO_POOL_IDX(bio) ((bio)-&gt;bi_flags &gt;&gt; BIO_POOL_OFFSET)</p> <p>void bio_free(struct bio *bio, struct bio_set *bs)<br/> {<br/> void *p;</p> <p>if (bio_has_allocated_vec(bio))<br/> bvec_free_bs(bs, bio-&gt;bi_io_vec, BIO_POOL_IDX(bio));</p> <p>...<br/> BIO_POOL_IDX()</p> <p>void bvec_free_bs(struct bio_set *bs, struct bio_vec *bv, unsigned int idx)<br/> {<br/> BIO_BUG_ON(idx &gt;= BIOVEC_NR_POOLS);</p> <p>with RDONLY set BIO_POOL_IDX() can get larger than BIOVEC_NR_POOLS and we hit the assertion.</p> RHEL6 LU-684

replace dev_rdonly kernel patch with dm-flakey

Technical task LU-20 Critical Resolved Fixed Oleg Drokin Alex Zhuravlev cea llnl Wed, 14 Sep 2011 08:33:08 +0000 Tue, 10 Apr 2018 06:25:29 +0000 Thu, 15 Mar 2018 14:04:25 +0000 Lustre 2.4.0 Lustre 2.8.0 Lustre 2.11.0 0 20 <p>small addition from my side. This is not just theoretical issue, I hit kernel bug during OST recovery testing with rhel6 and ext4. </p> <p>comparing rhel6 rdonly patch with rhel5 one I found that flag BIO_RDONLY is not used in rhel5 patch at all. Moreover it is not checked in lustre/rhel6 code also, so I wonder can it be just removed?</p> <p>There needs<img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/help_16.png" height="16" width="16" align="absmiddle" alt="" border="0"/> to be some mechanism by which the block device can be made to discard writes, so that recovery testing can work.</p> <p>That said, dev_read_only() is one of the very last remaining kernel patches that is needed, and getting rid of it would be a huge step toward patchless kernels. The only other <em>required</em> patch today is jbd2-jcberr (for the journal commit callback), but <a href="https://jira.whamcloud.com/browse/LU-433" title="remove jbd2-jcberr patch from kernel" class="issue-link" data-issue-key="LU-433"><del>LU-433</del></a> (<a href="http://review.whamcloud.com/#change,983" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,983</a>) is ready to remove this patch, and the remaining patches in the RHEL6 kernel series are only for compatibility and/or performance.</p> <p>The two uses that I'm aware of that need dev_rdonly functionality are:</p> <ul class="alternate" type="square"> <li>avoiding waiting on the disk for failback of targets. I'm not sure this is a valid usage, and I recall that Fan Yong may have removed this at some point to fix other problems (filesystem never being clean after unmount)</li> <li>creating a write barrier during failover testing.</li> </ul> <p>If this could be handled inside the OSD in some manner it would be ideal, but I'm not sure that is possible if there are dependent operations being done. For example, if "mkdir foo; touch foo/bar" is done then as long as this state is only present in the OSD cache and not on disk, we might be able to drop this patch entirely. It wouldn't actually handle testing of interrupted mid-stream transactions, if we have tests that do this today, as opposed to just a write barrier between to filesystem-level operations.</p> <p>The other issue is that dev_read_only is not usable for ZFS, because the pool could abort if it is missing commits that it thought were flushed to disk. I recall that Ricardo was investigating this, but I don't recall if there was any outcome?</p> <p>there is full-feature "read-only" called freeze in DMU, where basically everything is flushed except uber-block.</p> <p>with ldiskfs we easily can get corrupted image because some blocks are purged from the memory while another are not.</p> <p>I also note that Linux 3.1 has a "dm-flakey" target for device mapper, which supports a "drop_writes" option that could be used in place of our dev_read_only kernel patch. This means we would need to configure DM/LVM for all of our testing environments, but it wouldn't be needed for production use.</p> <p>Change topic to reflect that it is now focussed on removing the dev-readonly patch entirely from the kernel patches, since this is one of the few remaining patches that is required for Lustre servers.</p> <p>With the work going on to support SLES11 SP2 and FC18 the discussion has merged about going a patch less as possible. Now that RHEL5 is no longer supported server side we can move to using dm-flakey. Looking at the current code it seems the dev_read_only_patch is needed to support the OBD_IOC_SET_READONLY ioctl. The approach I'm thinking of is to have the lustre utils call dm-setup to handle setting the disk to read only. The question is does this approach work for ZFS as well?</p> <p>I'd say that ZFS's approach is better for this purpose because it keep the filesystem consisten being read-only. on ldisks we rely on luck basically, any read on RO-enabled filesystem may lead to wrong/stale data.</p> <p>You are talking about osd-zfs calling spa_freeze kernel side. So for the ldiskfs case we have to make calls into the dm_flakey kernel driver to support this same functionality.</p> <p>Now that the major work of 2.4 is done its time to look at this again. I spent some time looking at using fault injection that Linux supports. In order for this to work some extra setup has to be done on the test box. First the kernel needs to be configured with CONFIG_FAIL_MAKE_REQUEST. Currently RHEL6 kernels only build this for debug kernels. So the first setup is too decided do we want to do lustre testing with debug kernels only or enable this feature with standard kernels being built with lbuild. After that we can handle setting fail_make_request two ways. One is mount debugfs and set the values we want or set the fail_make_request vales on the linux kernel command line.<br/> For Lustre the latter choice seems the logical one. Either way the options we need to set is </p> <p>&lt;interval&gt;,&lt;probability&gt;,&lt;space&gt;,&lt;times&gt;</p> <p>For our testing the defaults that make sense are interval=0, probability=100, space=0, times=&#45;1. Once we have that setup then its a matter of flipping make_it_fail in struct hd_struct (blkdev-&gt;-&gt;bd_part).</p> <p>As you can see coding would not be difficult to do. Its the setup that would require more work.</p> <p>I do see how dm_flakey can replay rdonly patch, but this approach has been known to bring issues when we need to read data back. would it be possible to skip writes, but save data for subsequent reads ?</p> <p>Alex can you point me to reproducer for what you are talking about. I just set up my test system to use the fail_make_request code. One thing I don't see is how are you putting the disk back into read/write mode. I don't see dev_clear_rdonly being used anywhere.</p> <p>well, we've already seen few times this with ldiskfs/mballoc which verifies on-disk structure on load and assert if they don't match other structures (already in memory).<br/> dev_clear_rdonly is called in __blkdev_put() at umount time.</p> <p>After I pieced together the fault injection system I noticed that it disables access to the disk for both reads and writes. Is their a reason why the fail over test set the disk to read access only? If our test case requires blocking writes only then we will have to go with the dm-flaky driver and fix the mballoc issues.</p> <p>yes, the reason is to "forget" writes to simulate poweroff when buffered writes are lost.</p> <p>Would disabling the reads alter the out come of the fail over tests?</p> <p>I think so. inbetween turning the device read-only and failover we usually still do some processing, which in turn, may need to read something from disk.</p> <p>There is a patch in gerrit for this work - <a href="http://review.whamcloud.com/#/c/6651/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6651/</a></p> <p>I think we can create a kernel module like loop device. And modify mount_lustre.c to support a option like '-o disw', Provide a parameter via ioctl() to control this module to discard write or not. This module just can be used in test and avoid it may hurt production environment. After this work done, we can get rid of dev_readonly patch. </p> <p>That's essentially what dm-flakey does, and has the added benefit of being in the kernel already. </p> <p>there is a panic during using dm-flakey,</p> <p>steps:<br/> echo "0 `blockdev --getsize $realdev` linear $realdev 0" | dmsetup create $md_dev<br/> (mount lustre with $md_dev)<br/> echo "0 `blockdev --getsize $realdev` flakey $realdev 0 0 20000 1 drop_writes" | dmsetup load $md_dev<br/> dmsetup suspend $md_dev<br/> dmsetup resume $md_dev</p> <p>BUG: unable to handle kernel paging request at ffff88015981afff<br/> IP: <span class="error">&#91;&lt;ffffffffa00252dc&gt;&#93;</span> corrupt_bio_data+0x6c/0xb0 <span class="error">&#91;dm_flakey&#93;</span><br/> PGD 1a86063 PUD 0 <br/> Oops: 0002 <a href="#1" target="_blank" rel="noopener">1</a> SMP <br/> last sysfs file: /sys/devices/virtual/block/dm-2/dm/suspended<br/> CPU 0 <br/> Modules linked in: dm_flakey lustre(U) ofd(U) osp(U) lod(U) ost(U) mdt(U) osd_ldiskfs(U) fsfilt_ldiskfs(U) ldiskfs(U) exportfs mdd(U) mgs(U) lquota(U) lfsck(U) jbd obdecho(U) mgc(U) lov(U) osc(U) mdc(U) lmv(U) fid(U) fld(U) ptlrpc(U) obdclass(U) lvfs(U) ksocklnd(U) lnet(U) sha512_generic sha256_generic crc32c_intel libcfs(U) ipv6 microcode sg uvcvideo videodev v4l2_compat_ioctl32 i2c_core snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support virtio_balloon shpchp e1000 ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom ahci pata_acpi ata_generic ata_piix virtio_pci virtio_ring virtio dm_mirror dm_region_hash dm_log dm_mod <span class="error">&#91;last unloaded: scsi_wait_scan&#93;</span></p> <p>Pid: 2544, comm: loop0 Not tainted 2.6.32 #2 Parallels Software International Inc. Parallels Virtual Platform/Parallels Virtual Platform<br/> RIP: 0010:<span class="error">&#91;&lt;ffffffffa00252dc&gt;&#93;</span> <span class="error">&#91;&lt;ffffffffa00252dc&gt;&#93;</span> corrupt_bio_data+0x6c/0xb0 <span class="error">&#91;dm_flakey&#93;</span><br/> RSP: 0018:ffff88007c177dd0 EFLAGS: 00010297<br/> RAX: ffff88005981b000 RBX: 0000000000000000 RCX: 0000000000000000<br/> RDX: 00000000ffffffff RSI: ffff88005ee42280 RDI: ffff88007910cc00<br/> RBP: ffff88007c177de0 R08: ffff88007910cc00 R09: 0000000000000000<br/> R10: 0000000000001000 R11: 0000000000000000 R12: ffff88007910cc00<br/> R13: ffff88007ac578b8 R14: ffff88007c0b4c00 R15: ffff88007ac41290<br/> FS: 0000000000000000(0000) GS:ffff88000c400000(0000) knlGS:0000000000000000<br/> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b<br/> CR2: ffff88015981afff CR3: 0000000001a85000 CR4: 00000000001406f0<br/> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br/> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br/> Process loop0 (pid: 2544, threadinfo ffff88007c176000, task ffff88007c3ec040)<br/> Stack:<br/> 0000000000000000 ffff880000000000 ffff88007c177e00 ffffffffa0025373<br/> &lt;d&gt; 0000000000001000 ffff880000000000 ffff88007c177e40 ffffffffa00018af<br/> &lt;d&gt; 0000100000001000 ffff88007aeea600 ffff88007aeea714 ffff88007c177e80<br/> Call Trace:<br/> <span class="error">&#91;&lt;ffffffffa0025373&gt;&#93;</span> flakey_end_io+0x53/0x60 <span class="error">&#91;dm_flakey&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa00018af&gt;&#93;</span> clone_endio+0x5f/0xd0 <span class="error">&#91;dm_mod&#93;</span><br/> <span class="error">&#91;&lt;ffffffff811b149d&gt;&#93;</span> bio_endio+0x1d/0x40<br/> <span class="error">&#91;&lt;ffffffff8135ebff&gt;&#93;</span> loop_thread+0xdf/0x270<br/> <span class="error">&#91;&lt;ffffffff810920d0&gt;&#93;</span> ? autoremove_wake_function+0x0/0x40<br/> <span class="error">&#91;&lt;ffffffff8135eb20&gt;&#93;</span> ? loop_thread+0x0/0x270<br/> <span class="error">&#91;&lt;ffffffff81091d66&gt;&#93;</span> kthread+0x96/0xa0<br/> <span class="error">&#91;&lt;ffffffff8100c14a&gt;&#93;</span> child_rip+0xa/0x20<br/> <span class="error">&#91;&lt;ffffffff81091cd0&gt;&#93;</span> ? kthread+0x0/0xa0<br/> <span class="error">&#91;&lt;ffffffff8100c140&gt;&#93;</span> ? child_rip+0x0/0x20<br/> Code: 03 48 0f af c1 48 b9 00 00 00 00 00 88 ff ff 48 c1 e0 0c 48 01 c8 48 01 d0 74 08 8b 56 28 44 39 d2 76 02 c9 c3 8b 4e 30 83 ea 01 &lt;88&gt; 0c 10 4c 8b 4f 20 48 8b 07 8b 4e 28 44 89 ca 83 e2 01 83 fa <br/> RIP <span class="error">&#91;&lt;ffffffffa00252dc&gt;&#93;</span> corrupt_bio_data+0x6c/0xb0 <span class="error">&#91;dm_flakey&#93;</span><br/> RSP &lt;ffff88007c177dd0&gt;<br/> CR2: ffff88015981afff<br/> --<del>[ end trace a7cecfc161703a56 ]</del>--<br/> Kernel panic - not syncing: Fatal exception<br/> Pid: 2544, comm: loop0 Tainted: G D --------------- 2.6.32 #2<br/> Call Trace:<br/> <span class="error">&#91;&lt;ffffffff814fd57a&gt;&#93;</span> ? panic+0xa0/0x168<br/> <span class="error">&#91;&lt;ffffffff81501714&gt;&#93;</span> ? oops_end+0xe4/0x100<br/> <span class="error">&#91;&lt;ffffffff81043bab&gt;&#93;</span> ? no_context+0xfb/0x260<br/> <span class="error">&#91;&lt;ffffffff81043e35&gt;&#93;</span> ? __bad_area_nosemaphore+0x125/0x1e0<br/> <span class="error">&#91;&lt;ffffffff8104f2bd&gt;&#93;</span> ? check_preempt_curr+0x6d/0x90<br/> <span class="error">&#91;&lt;ffffffff81043f03&gt;&#93;</span> ? bad_area_nosemaphore+0x13/0x20<br/> <span class="error">&#91;&lt;ffffffff81044661&gt;&#93;</span> ? __do_page_fault+0x321/0x480<br/> <span class="error">&#91;&lt;ffffffff81060262&gt;&#93;</span> ? default_wake_function+0x12/0x20<br/> <span class="error">&#91;&lt;ffffffff810920e6&gt;&#93;</span> ? autoremove_wake_function+0x16/0x40<br/> <span class="error">&#91;&lt;ffffffff8135d751&gt;&#93;</span> ? transfer_none+0xa1/0xc0<br/> <span class="error">&#91;&lt;ffffffff8135d581&gt;&#93;</span> ? lo_splice_actor+0x81/0xc0<br/> <span class="error">&#91;&lt;ffffffff811a7829&gt;&#93;</span> ? page_cache_pipe_buf_release+0x19/0x30<br/> <span class="error">&#91;&lt;ffffffff810724c7&gt;&#93;</span> ? current_fs_time+0x27/0x30<br/> <span class="error">&#91;&lt;ffffffff8135d500&gt;&#93;</span> ? lo_splice_actor+0x0/0xc0<br/> <span class="error">&#91;&lt;ffffffff815036ce&gt;&#93;</span> ? do_page_fault+0x3e/0xa0<br/> <span class="error">&#91;&lt;ffffffff81500a85&gt;&#93;</span> ? page_fault+0x25/0x30<br/> <span class="error">&#91;&lt;ffffffffa00252dc&gt;&#93;</span> ? corrupt_bio_data+0x6c/0xb0 <span class="error">&#91;dm_flakey&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa0025373&gt;&#93;</span> ? flakey_end_io+0x53/0x60 <span class="error">&#91;dm_flakey&#93;</span><br/> <span class="error">&#91;&lt;ffffffffa00018af&gt;&#93;</span> ? clone_endio+0x5f/0xd0 <span class="error">&#91;dm_mod&#93;</span><br/> <span class="error">&#91;&lt;ffffffff811b149d&gt;&#93;</span> ? bio_endio+0x1d/0x40<br/> <span class="error">&#91;&lt;ffffffff8135ebff&gt;&#93;</span> ? loop_thread+0xdf/0x270<br/> <span class="error">&#91;&lt;ffffffff810920d0&gt;&#93;</span> ? autoremove_wake_function+0x0/0x40<br/> <span class="error">&#91;&lt;ffffffff8135eb20&gt;&#93;</span> ? loop_thread+0x0/0x270<br/> <span class="error">&#91;&lt;ffffffff81091d66&gt;&#93;</span> ? kthread+0x96/0xa0<br/> <span class="error">&#91;&lt;ffffffff8100c14a&gt;&#93;</span> ? child_rip+0xa/0x20<br/> <span class="error">&#91;&lt;ffffffff81091cd0&gt;&#93;</span> ? kthread+0x0/0xa0<br/> <span class="error">&#91;&lt;ffffffff8100c140&gt;&#93;</span> ? child_rip+0x0/0x20</p> <p>is there any other means to load the "flakey" table on demand except "suspend"+"resume"?</p> <p>status update:</p> <p>1, the problem in dm-flakey(drivers/md/dm-flakey.c" was found, which "corrupt_bio_data" feature is always applied even it isn't specified in the table.<br/> 2, the test-framework is modified to use the dm-flakey, and the replay tests pass locally (it's a little complex for it uses loop device, and these loop device<br/> will need to be cleaned up after test)</p> <p>the patch still need to some improvement, especially about the creation/deletion of "loop device"(from file) and "dm device"(from normal block device).</p> <p>the initial patch is tracked at <a href="http://review.whamcloud.com/#/c/7200/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7200/</a></p> <p>So much better than my patch. No kernel side work needed <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Hongchao,<br/> Will you be able to refresh this patch for 2.7?<br/> thank you!</p> <p>status update:<br/> the patch is in the test and will push it to Gerrit soon.</p> <p>the patch has been updated</p> <blockquote> <p>The two uses that I'm aware of that need dev_rdonly functionality are:</p> <ul> <li>avoiding waiting on the disk for failback of targets. I'm not sure this is a valid usage, and I recall that Fan Yong may have removed this at some point to fix other problems (filesystem never being clean after unmount)</li> <li>creating a write barrier during failover testing.</li> </ul> </blockquote> <p>For the first point, you mean avoiding the delay waiting for service shutdown, or avoiding the delay of having to wait for writes to flush before starting the service again (on the other node)?<br/> Because the "insure writing stops before service restart" seems like a vital requirement, and so I wonder if this functionality can't live just in the test-framework, but needs to be integrated more closely into Lustre itself; whenever a service is shutdown for failover, the service shutdown should really wait for the writes to flush or drop the writes.</p> <p>Patch is updated at <a href="http://review.whamcloud.com/#/c/7200" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7200</a></p> <p>I'm running locally with the 7200 patch with no problems but I see issues in Maloo. The logs reported lack important information. Can some look into why this patch is failing when it shouldn't be.</p> <p>I know work is under way on this ticket. It would be nice to get a status update here, since the last comment was from two years ago.</p> <p>Patch <a href="http://review.whamcloud.com/7200" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7200</a> passed local testing on master branch. It's pending testing by autotest and review.</p> <p>I have dropped the priority to Critical rather than Blocker to more accurately reflect the sitaution with this important enhancement </p> <p>Work is still ongoing for this effort but may not make 2.9</p> <p>Can we make sure it lands into 2.10 ?</p> <p>Jean have you been testing this patch?</p> <p>Yes, James. However, testing on the patch is blocked by <a href="https://jira.whamcloud.com/browse/LU-8729" title="conf-sanity test_84: FAIL: /dev/mapper/mds1_flakey failed to initialize!" class="issue-link" data-issue-key="LU-8729"><del>LU-8729</del></a> now. The issue is:<br/> <a href="https://jira.hpdd.intel.com/browse/LU-8729?focusedCommentId=180716&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-180716" class="external-link" target="_blank" rel="nofollow noopener">https://jira.hpdd.intel.com/browse/LU-8729?focusedCommentId=180716&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-180716</a></p> <p><a href="https://jira.whamcloud.com/browse/LU-8729" title="conf-sanity test_84: FAIL: /dev/mapper/mds1_flakey failed to initialize!" class="issue-link" data-issue-key="LU-8729"><del>LU-8729</del></a> no longer blocks this patch. Its been tested and reviewed.</p> <p>Is it still planned to land this work for 2.11?</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/7200/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/7200/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-684" title="replace dev_rdonly kernel patch with dm-flakey" class="issue-link" data-issue-key="LU-684"><del>LU-684</del></a> tests: replace dev_read_only patch with dm-flakey<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 54b9e3f789358bd9dfb94b77fe33a4faa1e28ab2</p> <p>Landed for 2.11</p> Blocker LU-8729 Related LU-4416 LU-10893 LU-9111 Development Rank 1|hzvcgv: Rank (Obsolete) 5605 Story Points 2.0