Hello, Joseph.
On Thu, Sep 13, 2012 at 01:10:13PM +1000, Joseph Glanville wrote:
> While reviewing some of the documentation in Documentation/block I
> found there is still out of date references to the old barrier code.
> Should this also be removed?
> I am not sufficiently confident of my
Hello, Joseph.
On Thu, Sep 13, 2012 at 01:10:13PM +1000, Joseph Glanville wrote:
While reviewing some of the documentation in Documentation/block I
found there is still out of date references to the old barrier code.
Should this also be removed?
I am not sufficiently confident of my
On 13 September 2012 09:53, Joseph Glanville
wrote:
> On 13 September 2012 09:20, Tejun Heo wrote:
>> On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
>>> diff --git a/block/blk-core.c b/block/blk-core.c
>>> index 4b4dbdf..68b5671 100644
>>> --- a/block/blk-core.c
>>> +++
On 13 September 2012 09:20, Tejun Heo wrote:
> On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
>> diff --git a/block/blk-core.c b/block/blk-core.c
>> index 4b4dbdf..68b5671 100644
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -1809,6 +1809,9 @@
On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 4b4dbdf..68b5671 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1809,6 +1809,9 @@ EXPORT_SYMBOL(generic_make_request);
> * uses that function to do most of
On 13 September 2012 04:58, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 11, 2012 at 10:25:01AM +0200, Lars Ellenberg wrote:
>> Or do we have a better place to document write ordering requirements?
>>
>> "To enforce write-after-write dependencies, you *have* to drain the
>> queue (do we have a
Hello,
On Tue, Sep 11, 2012 at 10:25:01AM +0200, Lars Ellenberg wrote:
> Or do we have a better place to document write ordering requirements?
>
> "To enforce write-after-write dependencies, you *have* to drain the
> queue (do we have a generic interface available for that?),
> or at least wait
Hello,
On Tue, Sep 11, 2012 at 10:25:01AM +0200, Lars Ellenberg wrote:
Or do we have a better place to document write ordering requirements?
To enforce write-after-write dependencies, you *have* to drain the
queue (do we have a generic interface available for that?),
or at least wait for
On 13 September 2012 04:58, Tejun Heo t...@kernel.org wrote:
Hello,
On Tue, Sep 11, 2012 at 10:25:01AM +0200, Lars Ellenberg wrote:
Or do we have a better place to document write ordering requirements?
To enforce write-after-write dependencies, you *have* to drain the
queue (do we have a
On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..68b5671 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1809,6 +1809,9 @@ EXPORT_SYMBOL(generic_make_request);
* uses that function to do most of the
On 13 September 2012 09:20, Tejun Heo t...@kernel.org wrote:
On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..68b5671 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1809,6 +1809,9 @@
On 13 September 2012 09:53, Joseph Glanville
joseph.glanvi...@orionvm.com.au wrote:
On 13 September 2012 09:20, Tejun Heo t...@kernel.org wrote:
On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..68b5671 100644
---
On Tue, Sep 11, 2012 at 10:25:01AM +0200, Lars Ellenberg wrote:
[..]
> "To enforce write-after-write dependencies, you *have* to drain the
> queue (do we have a generic interface available for that?),
> or at least wait for the completion of all the requests you
> (potentially) depend upon,
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
> Hello, again.
>
> cc'ing Kent and Vivek. The original thread is at
>
> http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
>
> On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
> > > We can possibly work around
On Tue, Sep 11, 2012 at 03:58:20PM +1000, NeilBrown wrote:
> On Mon, 10 Sep 2012 16:31:59 -0700 Kent Overstreet
> wrote:
>
> > cc'ing Neil
> >
> > On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
> > > Hello, again.
> > >
> > > cc'ing Kent and Vivek. The original thread is at
> > >
On Tue, Sep 11, 2012 at 03:58:20PM +1000, NeilBrown wrote:
On Mon, 10 Sep 2012 16:31:59 -0700 Kent Overstreet koverstr...@google.com
wrote:
cc'ing Neil
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
Hello, again.
cc'ing Kent and Vivek. The original thread is at
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
Hello, again.
cc'ing Kent and Vivek. The original thread is at
http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
We can possibly work around that by
On Tue, Sep 11, 2012 at 10:25:01AM +0200, Lars Ellenberg wrote:
[..]
To enforce write-after-write dependencies, you *have* to drain the
queue (do we have a generic interface available for that?),
or at least wait for the completion of all the requests you
(potentially) depend upon, before
On Mon, 10 Sep 2012 16:31:59 -0700 Kent Overstreet
wrote:
> cc'ing Neil
>
> On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
> > Hello, again.
> >
> > cc'ing Kent and Vivek. The original thread is at
> >
> > http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
> >
> > On
cc'ing Neil
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
> Hello, again.
>
> cc'ing Kent and Vivek. The original thread is at
>
> http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
>
> On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
> > > We can possibly
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
> Hello, again.
>
> cc'ing Kent and Vivek. The original thread is at
>
> http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
>
> On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
> > > We can possibly work around
Hello, again.
cc'ing Kent and Vivek. The original thread is at
http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
> > We can possibly work around that by introducing an additional submitter
> > thread,
> > or at least our
Hello, Lars.
On Fri, Sep 07, 2012 at 10:42:21AM +0200, Lars Ellenberg wrote:
> We have a kernel thread that is receiving data blocks,
> and some "boundary" information (in the sense that between such
> boundaries, we have a reorder domain, where requests may reorder freely,
> but no requests may
Hello, Lars.
On Fri, Sep 07, 2012 at 10:42:21AM +0200, Lars Ellenberg wrote:
We have a kernel thread that is receiving data blocks,
and some boundary information (in the sense that between such
boundaries, we have a reorder domain, where requests may reorder freely,
but no requests may be
Hello, again.
cc'ing Kent and Vivek. The original thread is at
http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
We can possibly work around that by introducing an additional submitter
thread,
or at least our own
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
Hello, again.
cc'ing Kent and Vivek. The original thread is at
http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
We can possibly work around that by
cc'ing Neil
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
Hello, again.
cc'ing Kent and Vivek. The original thread is at
http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
On Mon, Sep 10, 2012 at 03:54:42PM -0700, Tejun Heo wrote:
We can possibly work around
On Mon, 10 Sep 2012 16:31:59 -0700 Kent Overstreet koverstr...@google.com
wrote:
cc'ing Neil
On Mon, Sep 10, 2012 at 04:06:54PM -0700, Tejun Heo wrote:
Hello, again.
cc'ing Kent and Vivek. The original thread is at
http://thread.gmane.org/gmane.linux.network.drbd.devel/2130
On Thu, Sep 06, 2012 at 02:29:52PM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 05, 2012 at 12:07:24PM +0200, Lars Ellenberg wrote:
> > So reiterating the situation:
> >
> > If I'd submit a non-empty bio with FLUSH/FUA set,
> > on a queue that does support flush, we get to
> >
On Thu, Sep 06, 2012 at 02:29:52PM -0700, Tejun Heo wrote:
Hello,
On Wed, Sep 05, 2012 at 12:07:24PM +0200, Lars Ellenberg wrote:
So reiterating the situation:
If I'd submit a non-empty bio with FLUSH/FUA set,
on a queue that does support flush, we get to
blk_queue_bio()
Hello,
On Wed, Sep 05, 2012 at 12:07:24PM +0200, Lars Ellenberg wrote:
> So reiterating the situation:
>
> If I'd submit a non-empty bio with FLUSH/FUA set,
> on a queue that does support flush, we get to
> blk_queue_bio()
> if (bio->bi_rw & (REQ_FLUSH | REQ_FUA)) {
>
Hello,
On Wed, Sep 05, 2012 at 12:07:24PM +0200, Lars Ellenberg wrote:
So reiterating the situation:
If I'd submit a non-empty bio with FLUSH/FUA set,
on a queue that does support flush, we get to
blk_queue_bio()
if (bio-bi_rw (REQ_FLUSH | REQ_FUA)) {
On Wed, Sep 05, 2012 at 01:49:15AM -0700, Tejun Heo wrote:
> On Wed, Sep 05, 2012 at 10:44:55AM +0200, Philipp Reisner wrote:
> > > Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
> > > systems are responsible for draining all writes which have to happen
> > > before and not
On Wed, Sep 05, 2012 at 10:44:55AM +0200, Philipp Reisner wrote:
> > Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
> > systems are responsible for draining all writes which have to happen
> > before and not issue further writes which should come after.
>
> Ok. That is a
> Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
> systems are responsible for draining all writes which have to happen
> before and not issue further writes which should come after.
Ok. That is a clear statement. So we will do it that way.
The "Currently" in you statement,
Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
systems are responsible for draining all writes which have to happen
before and not issue further writes which should come after.
Ok. That is a clear statement. So we will do it that way.
The Currently in you statement,
On Wed, Sep 05, 2012 at 10:44:55AM +0200, Philipp Reisner wrote:
Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
systems are responsible for draining all writes which have to happen
before and not issue further writes which should come after.
Ok. That is a clear
On Wed, Sep 05, 2012 at 01:49:15AM -0700, Tejun Heo wrote:
On Wed, Sep 05, 2012 at 10:44:55AM +0200, Philipp Reisner wrote:
Currently, FLUSH/FUA doesn't enforce any ordering requirement. File
systems are responsible for draining all writes which have to happen
before and not issue
38 matches
Mail list logo
