mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Hannes Reinecke <hare@suse.de>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	chuck.lever@oracle.com, Christoph Hellwig <hch@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: status of block-integrity
Date: Tue, 07 Jan 2014 16:43:40 -0500	[thread overview]
Message-ID: <yq1a9f7wjqr.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <52CBAA1B.7000509@suse.de> (Hannes Reinecke's message of "Tue, 07 Jan 2014 08:17:47 +0100")

>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> 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, we find more issues there than we do between initiator and
target.

API issues aside, another reason adoption has been slow is that very few
applications truly care about this stuff. The current approach in which
data is protected when the I/O is submitted by the filesystem is good
enough for most things. Saves the filesystem people the trouble of
dealing with it too.

In reality there are only a handful of applications that would actually
benefit from an explicit userland API. Mostly in the database
department. All the potential consumers of an interface I talked to
wanted to use aio so that's why we've focused our efforts there.

Both Darrick and I have been busy with other projects the last little
while. I'll start looking at this again when I'm done with copy
offload...

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2014-01-07 21:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-22 19:21 Christoph Hellwig
2013-12-22 20:45 ` Nicholas A. Bellinger
2013-12-23 13:35 ` Martin K. Petersen
2013-12-23 13:48   ` Christoph Hellwig
2013-12-31 19:41   ` berthiaume, wayne
2014-01-07  8:28   ` Ric Wheeler
2014-01-07 13:33     ` Hannes Reinecke
2014-01-07 23:34       ` Matthew Wilcox
2014-01-08  0:05         ` James Bottomley
2014-01-08 15:43           ` Martin K. Petersen
2014-01-03 15:01 ` Hannes Reinecke
2014-01-03 20:03   ` Martin K. Petersen
2014-01-07  1:36     ` Darrick J. Wong
2014-01-07  7:17       ` Hannes Reinecke
2014-01-07 21:43         ` Martin K. Petersen [this message]
2014-01-08  7:14           ` Hannes Reinecke
2014-01-08 15:23             ` Martin K. Petersen
2014-01-09 11:19               ` Hannes Reinecke
2014-01-10  1:49                 ` Martin K. Petersen
2014-01-07 15:06       ` Chuck Lever

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=yq1a9f7wjqr.fsf@sermon.lab.mkp.net \
    --to=martin.petersen@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=chuck.lever@oracle.com \
    --cc=darrick.wong@oracle.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®