On 7 February 2013 12:54, Amit Kale wrote:
>> -Original Message-
>> From: Kent Overstreet [mailto:koverstr...@google.com]
>> Sent: Wednesday, February 06, 2013 4:01 PM
>> To: Amit Kale
>> Cc: Michel Lespinasse; Darrick J. Wong; linux-bcache; device-mapper
>> development; Kent Overstreet;
On 7 February 2013 12:54, Amit Kale ak...@stec-inc.com wrote:
-Original Message-
From: Kent Overstreet [mailto:koverstr...@google.com]
Sent: Wednesday, February 06, 2013 4:01 PM
To: Amit Kale
Cc: Michel Lespinasse; Darrick J. Wong; linux-bcache; device-mapper
development; Kent
On 31 October 2012 05:25, Behan Webster wrote:
> The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
> precludes the use of compilers which don't implement VLAIS (for instance the
> Clang compiler). This patch instead calculates offsets into the kmalloc-ed
> memory
On 31 October 2012 05:25, Behan Webster beh...@converseincode.com wrote:
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This patch instead calculates offsets into the
which needs or wants working elevator and blk-cgroup on a queue
>> which isn't visible to userland. If there are such users, we need a
>> different solution.
>>
>> Signed-off-by: Tejun Heo
>> Reported-by: Joseph Glanville
>> Cc: Vivek Goyal
>> Cc: sta...@vge
Reported-by: Joseph Glanville joseph.glanvi...@orionvm.com.au
Cc: Vivek Goyal vgo...@redhat.com
Cc: sta...@vger.kernel.org
---
Jens, while these are fixes, I think it isn't extremely urgent and
routing these through 3.7-rc1 should be enough.
Agree, I'll shove them into for-3.7/core
--
Jens
From: Joseph Glanville
It is worth noting here that the block layer makes no attempt
to preserve the order of requests and that upper layers like
journaling filesystems that require such ordering need to do so
explicity.
Signed-off-by: Joseph Glanville
---
block/blk-core.c | 6 ++
1 file
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
>>&
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
>> @@
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
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 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 @@ EXPORT_SYMBOL
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
From: Joseph Glanville joseph.glanvi...@orionvm.com.au
It is worth noting here that the block layer makes no attempt
to preserve the order of requests and that upper layers like
journaling filesystems that require such ordering need to do so
explicity.
Signed-off-by: Joseph Glanville
Hi Kent, Tejun
On 9 August 2012 09:57, Kent Overstreet wrote:
>> Also, how was this tested?
>
> Well, AFAICT the only request based dm target is multipath, and from the
> documentation I've seen it doesn't appear to work without multipath
> hardware, or at least I haven't seen it documented how.
Hi Kent, Tejun
On 9 August 2012 09:57, Kent Overstreet koverstr...@google.com wrote:
Also, how was this tested?
Well, AFAICT the only request based dm target is multipath, and from the
documentation I've seen it doesn't appear to work without multipath
hardware, or at least I haven't seen it
16 matches
Mail list logo
