From: Doug Dumitru <doug@easyco.com>
To: Robert LeBlanc <robert@leblancnet.us>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Question about raid1_make_request
Date: Mon, 28 Nov 2016 15:53:02 -0800 [thread overview]
Message-ID: <CAFx4rwQQrETbpi-kQ56wj3izmvSpDiCQ3iD6dyK2LkkM-JZBTg@mail.gmail.com> (raw)
In-Reply-To: <CAANLjFpb0ZCEVtvaib8nsoKhKZs55agy35HEByeo1g1OSWBGjg@mail.gmail.com>
Not the best code organization, but no real harm done. Look at the
front of md_write_start:
void md_write_start(struct mddev *mddev, struct bio *bi)
{
int did_change = 0;
if (bio_data_dir(bi) != WRITE)
return;
So writes fall thru really quickly.
Doug
On Mon, Nov 28, 2016 at 3:41 PM, Robert LeBlanc <robert@leblancnet.us> wrote:
> I'm looking through the code and am wondering why this is at the start
> of raid1_make_request. It seems that it is only needed for WRITE and
> would unnecessarily delay READ requests waiting for the superblock.
> Would it make more sense to put this at the start of the WRITE branch?
> What am I missing?
>
> 1057 /*
> 1058 * Register the new request and wait if the
> reconstruction
> 1059 * thread has put up a bar for new requests.
> 1060 * Continue immediately if no resync is active currently.
> 1061 */
> 1062
> 1063 md_write_start(mddev, bio); /* wait on superblock update
> early */
> 1064
> 1065 if (bio_data_dir(bio) == WRITE &&
> 1066 ((bio_end_sector(bio) > mddev->suspend_lo &&
> 1067 bio->bi_iter.bi_sector < mddev->suspend_hi) ||
> 1068 (mddev_is_clustered(mddev) &&
> 1069 md_cluster_ops->area_resyncing(mddev, WRITE,
> 1070 bio->bi_iter.bi_sector,
> bio_end_sector(bio))))) {
> 1071 /* As the suspend_* range is controlled by
> 1072 * userspace, we want an interruptible
> 1073 * wait.
> 1074 */
> 1075 DEFINE_WAIT(w);
> 1076 for (;;) {
> 1077 flush_signals(current);
> 1078 prepare_to_wait(&conf->wait_barrier,
> 1079 &w, TASK_INTERRUPTIBLE);
> 1080 if (bio_end_sector(bio) <=
> mddev->suspend_lo ||
> 1081 bio->bi_iter.bi_sector >=
> mddev->suspend_hi ||
> 1082 (mddev_is_clustered(mddev) &&
> 1083
> !md_cluster_ops->area_resyncing(mddev, WRITE,
> 1084 bio->bi_iter.bi_sector,
> bio_end_sector(bio))))
> 1085 break;
> 1086 schedule();
> 1087 }
> 1088 finish_wait(&conf->wait_barrier, &w);
> 1089 }
> 1090
> 1091 start_next_window = wait_barrier(conf, bio);
> 1092
> 1093 bitmap = mddev->bitmap;
> 1094
>
> Thanks
>
> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Doug Dumitru
EasyCo LLC
next prev parent reply other threads:[~2016-11-28 23:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-28 23:41 Question about raid1_make_request Robert LeBlanc
2016-11-28 23:53 ` Doug Dumitru [this message]
2016-11-29 0:04 ` Robert LeBlanc
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=CAFx4rwQQrETbpi-kQ56wj3izmvSpDiCQ3iD6dyK2LkkM-JZBTg@mail.gmail.com \
--to=doug@easyco.com \
--cc=linux-raid@vger.kernel.org \
--cc=robert@leblancnet.us \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.