From: antlists <antlists@youngman.org.uk>
To: John Stoffel <john@stoffel.org>, Danny Shih <dannyshih@synology.com>
Cc: axboe@kernel.dk, agk@redhat.com, snitzer@redhat.com,
dm-devel@redhat.com, song@kernel.org,
linux-block@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/4] block: introduce submit_bio_noacct_add_head
Date: Wed, 30 Dec 2020 17:53:44 +0000 [thread overview]
Message-ID: <1b6c4709-8409-a73f-d3f0-4b4cf19bfae1@youngman.org.uk> (raw)
In-Reply-To: <24556.45969.276771.345181@quad.stoffel.home>
On 30/12/2020 17:06, John Stoffel wrote:
> Danny> "Provide a way for stacking block device to re-submit
>
> Danny> the bio which should be handled first."
>
> Danny> I will fix it.
>
> Great, though my second question is*why* it needs to be handled
> first? What is the difference between stacked and un-stacked devices
> and how could it be done in a way that doesn't require a seperate
> function like this?
Is this anything to do with what's on my mind as a database guy? I've
heard that things like RAID and LVM have difficulty providing write
barriers.
I want to be confident that, at EVERY level of the stack, I can put a
barrier in that guarantees that everything written by user-space BEFORE
the barrier is handled before anything written AFTER the barrier. That
way, I can be confident that, after a problem, I know whether I can
safely roll the log forward or back.
Cheers,
Wol
WARNING: multiple messages have this Message-ID (diff)
From: antlists <antlists@youngman.org.uk>
To: John Stoffel <john@stoffel.org>, Danny Shih <dannyshih@synology.com>
Cc: axboe@kernel.dk, linux-raid@vger.kernel.org, snitzer@redhat.com,
linux-block@vger.kernel.org, song@kernel.org,
dm-devel@redhat.com, agk@redhat.com
Subject: Re: [dm-devel] [PATCH 1/4] block: introduce submit_bio_noacct_add_head
Date: Wed, 30 Dec 2020 17:53:44 +0000 [thread overview]
Message-ID: <1b6c4709-8409-a73f-d3f0-4b4cf19bfae1@youngman.org.uk> (raw)
In-Reply-To: <24556.45969.276771.345181@quad.stoffel.home>
On 30/12/2020 17:06, John Stoffel wrote:
> Danny> "Provide a way for stacking block device to re-submit
>
> Danny> the bio which should be handled first."
>
> Danny> I will fix it.
>
> Great, though my second question is*why* it needs to be handled
> first? What is the difference between stacked and un-stacked devices
> and how could it be done in a way that doesn't require a seperate
> function like this?
Is this anything to do with what's on my mind as a database guy? I've
heard that things like RAID and LVM have difficulty providing write
barriers.
I want to be confident that, at EVERY level of the stack, I can put a
barrier in that guarantees that everything written by user-space BEFORE
the barrier is handled before anything written AFTER the barrier. That
way, I can be confident that, after a problem, I know whether I can
safely roll the log forward or back.
Cheers,
Wol
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2020-12-30 17:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-29 9:18 [PATCH 0/4] Fix order when split bio and send remaining back to itself dannyshih
2020-12-29 9:18 ` [dm-devel] " dannyshih
2020-12-29 9:18 ` [PATCH 1/4] block: introduce submit_bio_noacct_add_head dannyshih
2020-12-29 9:18 ` [dm-devel] " dannyshih
2020-12-30 0:00 ` John Stoffel
2020-12-30 0:00 ` [dm-devel] " John Stoffel
2020-12-30 9:51 ` Danny Shih
2020-12-30 9:51 ` [dm-devel] " Danny Shih
2020-12-30 17:06 ` John Stoffel
2020-12-30 17:06 ` [dm-devel] " John Stoffel
2020-12-30 17:53 ` antlists [this message]
2020-12-30 17:53 ` antlists
2020-12-30 11:35 ` antlists
2020-12-30 11:35 ` [dm-devel] " antlists
2020-12-30 16:53 ` John Stoffel
2020-12-30 16:53 ` [dm-devel] " John Stoffel
2020-12-29 9:18 ` [PATCH 2/4] block: use submit_bio_noacct_add_head for split bio sending back dannyshih
2020-12-29 9:18 ` [dm-devel] " dannyshih
2020-12-29 9:18 ` [PATCH 3/4] dm: " dannyshih
2020-12-29 9:18 ` [dm-devel] " dannyshih
2020-12-29 9:18 ` [PATCH 4/4] md: " dannyshih
2020-12-29 9:18 ` [dm-devel] " dannyshih
2020-12-30 23:34 ` [PATCH 0/4] Fix order when split bio and send remaining back to itself Mike Snitzer
2020-12-30 23:34 ` [dm-devel] " Mike Snitzer
2020-12-31 8:28 ` Danny Shih
2020-12-31 8:28 ` [dm-devel] " Danny Shih
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=1b6c4709-8409-a73f-d3f0-4b4cf19bfae1@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dannyshih@synology.com \
--cc=dm-devel@redhat.com \
--cc=john@stoffel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=snitzer@redhat.com \
--cc=song@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.