From: Dmitrii Tcvetkov <demfloro@demfloro.ru>
To: Timofey Titovets <nefelim4ag@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] Btrfs: enchanse raid1/10 balance heuristic
Date: Sat, 30 Dec 2017 11:14:04 +0300 [thread overview]
Message-ID: <20171230111404.4d424d95@xps.localdomain> (raw)
In-Reply-To: <CAGqmi74eMoBDGRJsZ6sSc3k5VrQvfK+WREvyxJxe9QM12FEH7w@mail.gmail.com>
On Sat, 30 Dec 2017 03:15:20 +0300
Timofey Titovets <nefelim4ag@gmail.com> wrote:
> 2017-12-29 22:14 GMT+03:00 Dmitrii Tcvetkov <demfloro@demfloro.ru>:
> > On Fri, 29 Dec 2017 21:44:19 +0300
> > Dmitrii Tcvetkov <demfloro@demfloro.ru> wrote:
> >> > +/**
> >> > + * guess_optimal - return guessed optimal mirror
> >> > + *
> >> > + * Optimal expected to be pid % num_stripes
> >> > + *
> >> > + * That's generaly ok for spread load
> >> > + * Add some balancer based on queue leght to device
> >> > + *
> >> > + * Basic ideas:
> >> > + * - Sequential read generate low amount of request
> >> > + * so if load of drives are equal, use pid % num_stripes
> >> > balancing
> >> > + * - For mixed rotate/non-rotate mirrors, pick non-rotate as
> >> > optimal
> >> > + * and repick if other dev have "significant" less queue
> >> > lenght
> >> > + * - Repick optimal if queue leght of other mirror are less
> >> > + */
> >> > +static int guess_optimal(struct map_lookup *map, int optimal)
> >> > +{
> >> > + int i;
> >> > + int round_down = 8;
> >> > + int num = map->num_stripes;
> >>
> >> num has to be initialized from map->sub_stripes if we're reading
> >> RAID10, otherwise there will be NULL pointer dereference
> >>
> >
> > Check can be like:
> > if (map->type & BTRFS_BLOCK_GROUP_RAID10)
> > num = map->sub_stripes;
> >
> >>@@ -5804,10 +5914,12 @@ static int __btrfs_map_block(struct
> >>btrfs_fs_info *fs_info,
> >> stripe_index += mirror_num - 1;
> >> else {
> >> int old_stripe_index = stripe_index;
> >>+ optimal = guess_optimal(map,
> >>+ current->pid %
> >>map->num_stripes);
> >> stripe_index = find_live_mirror(fs_info, map,
> >> stripe_index,
> >> map->sub_stripes,
> >> stripe_index +
> >>- current->pid %
> >>map->sub_stripes,
> >>+ optimal,
> >> dev_replace_is_ongoing);
> >> mirror_num = stripe_index - old_stripe_index
> >> + 1; }
> >>--
> >>2.15.1
> >
> > Also here calculation should be with map->sub_stripes too.
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-btrfs" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Why you think we need such check?
> I.e. guess_optimal always called for find_live_mirror()
> Both in same context, like that:
>
> if (map->type & BTRFS_BLOCK_GROUP_RAID10) {
> u32 factor = map->num_stripes / map->sub_stripes;
>
> stripe_nr = div_u64_rem(stripe_nr, factor, &stripe_index);
> stripe_index *= map->sub_stripes;
>
> if (need_full_stripe(op))
> num_stripes = map->sub_stripes;
> else if (mirror_num)
> stripe_index += mirror_num - 1;
> else {
> int old_stripe_index = stripe_index;
> stripe_index = find_live_mirror(fs_info, map,
> stripe_index,
> map->sub_stripes, stripe_index +
> current->pid % map->sub_stripes,
> dev_replace_is_ongoing);
> mirror_num = stripe_index - old_stripe_index + 1;
> }
>
> That useless to check that internally
My bad, so only need to call
guess_optimal(map, current->pid % map->sub_stripes)
in RAID10 branch.
next prev parent reply other threads:[~2017-12-30 8:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-29 2:09 [PATCH v2] Btrfs: enchanse raid1/10 balance heuristic Timofey Titovets
2017-12-29 18:44 ` Dmitrii Tcvetkov
2017-12-29 19:14 ` Dmitrii Tcvetkov
2017-12-30 0:15 ` Timofey Titovets
2017-12-30 8:14 ` Dmitrii Tcvetkov [this message]
2017-12-30 9:47 ` Timofey Titovets
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=20171230111404.4d424d95@xps.localdomain \
--to=demfloro@demfloro.ru \
--cc=linux-btrfs@vger.kernel.org \
--cc=nefelim4ag@gmail.com \
/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 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).