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 unders
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
>>> +++ b/block
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 @@ EXPORT_SYMBOL(generic_m
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 generi
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 f
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, 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
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 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 M
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 wor
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
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 ow
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 b
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_b
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 is
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 clea
> 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,
Hello,
On Tue, Sep 04, 2012 at 02:32:01PM +0200, Philipp Reisner wrote:
> I think commit 1e87901e18 was wrong. Starting with that commit the REQ_FLUSH
> and REQ_FUA bits get stripped away if the queue does not advertise REQ_FLUSH
> or REQ_FUA support.
>
> But the REQ_FLUSH bit is also tested for
Hi,
I think commit 1e87901e18 was wrong. Starting with that commit the REQ_FLUSH
and REQ_FUA bits get stripped away if the queue does not advertise REQ_FLUSH
or REQ_FUA support.
But the REQ_FLUSH bit is also tested for when not merging requests
(blk_queue_bio()) or when it comes to the elevator
21 matches
Mail list logo
