> "Hannes" == Hannes Reinecke writes:
Hannes> With LID1/XCopy you have the ambiguity on where to actually send
Hannes> the command to; the spec is silent in this area.
Yeah, right now it's a coin toss.
However, thanks to VAAI most arrays support LID1. I'm trying to leverage
that. Doesn't in
On 01/08/2014 04:23 PM, Martin K. Petersen wrote:
"Hannes" == Hannes Reinecke writes:
Hannes,
Hannes> As there is no user (apart from oracleasm) no-one can attach
Hannes> protection information to any data, so even the most dedicated
Hannes> admin cannot exercise this path, let alone find iss
> "James" == James Bottomley writes:
James> No, I think you're confusing algorithms with protocols. DIF and
James> DIX are two names for protection envelopes. DIF verifies
James> integrity from the HBA to the device surface. DIX verifies
James> integrity from an application to the HBA.
A
> "Hannes" == Hannes Reinecke writes:
Hannes,
Hannes> As there is no user (apart from oracleasm) no-one can attach
Hannes> protection information to any data, so even the most dedicated
Hannes> admin cannot exercise this path, let alone find issues here.
That's not how it works!
If the fil
On 01/07/2014 10:43 PM, Martin K. Petersen wrote:
>> "Hannes" == Hannes Reinecke writes:
>
> Hannes> Plus (as hch rightly pointed out) as there is no defined
> Hannes> userland interface the question is why we bother with all the
> Hannes> DIX stuff in the block layer.
>
> Because it catch
On Tue, 2014-01-07 at 16:34 -0700, Matthew Wilcox wrote:
> On Tue, Jan 07, 2014 at 02:33:10PM +0100, Hannes Reinecke wrote:
> > I would indeed like to have a discussion at LSF about the future of
> > DIX. DIF is not an issue, as most HBAs support it already and we
> > actually need it for proper co
On Tue, Jan 07, 2014 at 02:33:10PM +0100, Hannes Reinecke wrote:
> I would indeed like to have a discussion at LSF about the future of
> DIX. DIF is not an issue, as most HBAs support it already and we
> actually need it for proper connectivity.
>
> DIX, OTOH, has been left dormant since time imme
> "Hannes" == Hannes Reinecke writes:
Hannes> Plus (as hch rightly pointed out) as there is no defined
Hannes> userland interface the question is why we bother with all the
Hannes> DIX stuff in the block layer.
Because it catches problems in the path between block layer and HBA
ASIC? FWIW,
On Jan 6, 2014, at 8:36 PM, Darrick J. Wong wrote:
> On Fri, Jan 03, 2014 at 03:03:42PM -0500, Martin K. Petersen wrote:
>>> "Hannes" == Hannes Reinecke writes:
>>
>> Hannes> Personally, I doubt it's a good idea to kill it off, but a
>> Hannes> proper (userland) API for it has been a long
On 01/07/2014 09:28 AM, Ric Wheeler wrote:
> On 12/23/2013 09:35 PM, Martin K. Petersen wrote:
>>> "Christoph" == Christoph Hellwig writes:
>> Christoph> We have the block integrity code to support DIF/DIX in the
>> Christoph> the tree for about 5 and a half years, and we still don't
>> Christ
On 12/23/2013 09:35 PM, Martin K. Petersen wrote:
"Christoph" == Christoph Hellwig writes:
Christoph> We have the block integrity code to support DIF/DIX in the
Christoph> the tree for about 5 and a half years, and we still don't
Christoph> have a single consumer of it.
What do you mean? If yo
On 01/07/2014 02:36 AM, Darrick J. Wong wrote:
> On Fri, Jan 03, 2014 at 03:03:42PM -0500, Martin K. Petersen wrote:
>>> "Hannes" == Hannes Reinecke writes:
>>
>> Hannes> Personally, I doubt it's a good idea to kill it off, but a
>> Hannes> proper (userland) API for it has been a long time mis
On Fri, Jan 03, 2014 at 03:03:42PM -0500, Martin K. Petersen wrote:
> > "Hannes" == Hannes Reinecke writes:
>
> Hannes> Personally, I doubt it's a good idea to kill it off, but a
> Hannes> proper (userland) API for it has been a long time missing.
>
> Before we throw the baby out with the ba
> "Hannes" == Hannes Reinecke writes:
Hannes> Personally, I doubt it's a good idea to kill it off, but a
Hannes> proper (userland) API for it has been a long time missing.
Before we throw the baby out with the bath water, maybe Darrick can fill
us in on the progress of the aio passthrough in
On 12/22/2013 08:21 PM, Christoph Hellwig wrote:
We have the block integrity code to support DIF/DIX in the the tree for
about 5 and a half years, and we still don't have a single consumer of
it. By normal kernel rules it should never have been merged, or at
least the bitrot long removed.
Given
Axboe; linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org
Subject: Re: status of block-integrity
>>>>> "Christoph" == Christoph Hellwig writes:
Christoph> We have the block integrity code to support DIF/DIX in the
Christoph> the tree for about 5 and a
> "Christoph" == Christoph Hellwig writes:
Christoph> We have the block integrity code to support DIF/DIX in the
Christoph> the tree for about 5 and a half years, and we still don't
Christoph> have a single consumer of it.
What do you mean? If you have a DIX-capable HBA (lpfc, qla2xxx, zfc
On Mon, Dec 23, 2013 at 08:35:22AM -0500, Martin K. Petersen wrote:
> > "Christoph" == Christoph Hellwig writes:
>
> Christoph> We have the block integrity code to support DIF/DIX in the
> Christoph> the tree for about 5 and a half years, and we still don't
> Christoph> have a single consumer
On Sun, 2013-12-22 at 11:21 -0800, Christoph Hellwig wrote:
> We have the block integrity code to support DIF/DIX in the the tree for
> about 5 and a half years, and we still don't have a single consumer of
> it. By normal kernel rules it should never have been merged, or at
> least the bitrot lon
We have the block integrity code to support DIF/DIX in the the tree for
about 5 and a half years, and we still don't have a single consumer of
it. By normal kernel rules it should never have been merged, or at
least the bitrot long removed.
Given that we'll have a lot of work to do in this area w
20 matches
Mail list logo
