All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert LeBlanc <robert@leblancnet.us>
To: linux-raid@vger.kernel.org
Subject: Question about raid1_make_request
Date: Mon, 28 Nov 2016 16:41:22 -0700	[thread overview]
Message-ID: <CAANLjFpb0ZCEVtvaib8nsoKhKZs55agy35HEByeo1g1OSWBGjg@mail.gmail.com> (raw)

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

             reply	other threads:[~2016-11-28 23:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28 23:41 Robert LeBlanc [this message]
2016-11-28 23:53 ` Question about raid1_make_request Doug Dumitru
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=CAANLjFpb0ZCEVtvaib8nsoKhKZs55agy35HEByeo1g1OSWBGjg@mail.gmail.com \
    --to=robert@leblancnet.us \
    --cc=linux-raid@vger.kernel.org \
    /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.