From: Wang Shanker <firstname.lastname@example.org> To: Xiao Ni <email@example.com> Cc: Ming Lei <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [Bug Report] Discard bios cannot be correctly merged in blk-mq Date: Mon, 21 Jun 2021 15:49:33 +0800 [thread overview] Message-ID: <5EFF6838-7ED8-4B14-BD43-4D4E67628149@gmail.com> (raw) In-Reply-To: <CALTww29rcAwSfbpsBzM_pnVSuVTYyt-YJryeUaNkHetCjXktCg@mail.gmail.com> Hi, Xiao Many thanks for your reply. I realized that this problem is not limited to discard requests. For normal read/write requests, they are also first get split into 4k-sized ones and then merged into larger ones. The merging of bio's is limited by queue_max_segments, which leads to small trunks of io operations issued to physical devices. It seems that such behavior is not optimal and should be improved. I'm not so familiar with raid456. Could you have a look of its code when you are free? It seems that improving this may result in big changes. Cheers, Miao Wang > 2021年06月18日 20:49，Xiao Ni <email@example.com> 写道： > > Hi Miao > > So you plan to fix this problem now? The plan is to submit the discard > bio directly to disk similar with raid0/raid10. > As we talked, it needs to consider the discard region. It should be > larger than chunk_sectors * nr_data_disks. It needs > to split the bio when its size not aligned with chunk_sectors * > nr_data_disks. And it needs to consider the start address > of the bio too. If it's not aligned with a start address of > chunk_sectors, it's better to split this part too. > > I'm working on another job. So I don't have time to do this now. If > you submit the patches, I can help to review :) > > Regards > Xiao > > On Fri, Jun 18, 2021 at 2:28 PM Wang Shanker <firstname.lastname@example.org> wrote: >> >> Hi, Xiao >> >> Any ideas on this issue? >> >> Cheers, >> >> Miao Wang >> >>> 2021年06月09日 17:03，Wang Shanker <email@example.com> 写道： >>> >>>> >>>> 2021年06月09日 16:44，Xiao Ni <firstname.lastname@example.org> 写道： >>>> >>>> Hi all >>>> >>>> Thanks for reporting about this. I did a test in my environment. >>>> time blkdiscard /dev/nvme5n1 (477GB) >>>> real 0m0.398s >>>> time blkdiscard /dev/md0 >>>> real 9m16.569s >>>> >>>> I'm not familiar with the block layer codes. I'll try to understand >>>> the codes related with discard request and >>>> try to fix this problem. >>>> >>>> I have a question for raid5 discard, it needs to consider more than >>>> raid0 and raid10. For example, there is a raid5 with 3 disks. >>>> D11 D21 P1 (stripe size is 4KB) >>>> D12 D22 P2 >>>> D13 D23 P3 >>>> D14 D24 P4 >>>> ... (chunk size is 512KB) >>>> If there is a discard request on D13 and D14, and there is no discard >>>> request on D23 D24. It can't send >>>> discard request to D13 and D14, right? P3 = D23 xor D13. If we discard >>>> D13 and disk2 is broken, it can't >>>> get the right data from D13 and P3. The discard request on D13 can >>>> write 0 to the discard region, right? >>> >>> Yes. It can be seen at the beginning of make_discard_request(), where >>> the requested range being discarded is aligned to ``stripe_sectors", >>> which should be chunk_sectors * nr_data_disks. >>> >>> Cheers, >>> >>> Miao Wang >> >
next prev parent reply other threads:[~2021-06-21 7:49 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-05 20:54 Wang Shanker 2021-06-05 22:38 ` antlists 2021-06-06 3:44 ` Wang Shanker 2021-06-07 13:07 ` Ming Lei 2021-06-08 15:49 ` Wang Shanker 2021-06-09 0:41 ` Ming Lei 2021-06-09 2:40 ` Wang Shanker 2021-06-09 8:44 ` Xiao Ni 2021-06-09 9:03 ` Wang Shanker 2021-06-18 6:28 ` Wang Shanker 2021-06-18 12:49 ` Xiao Ni 2021-06-21 7:49 ` Wang Shanker [this message] 2021-06-22 1:48 ` Xiao Ni
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5EFF6838-7ED8-4B14-BD43-4D4E67628149@gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [Bug Report] Discard bios cannot be correctly merged in blk-mq' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).