All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: dm-devel@redhat.com, linux-kernel@vger.kernel.org, agk@sourceware.org
Subject: Re: Block integrity patches for 2.6.28
Date: Thu, 2 Oct 2008 18:29:56 +0200	[thread overview]
Message-ID: <20081002162955.GI19428@kernel.dk> (raw)
In-Reply-To: <yq1wsgrgl0o.fsf@sermon.lab.mkp.net>

On Thu, Oct 02 2008, Martin K. Petersen wrote:
> >>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:
> 
> Jens> As far as I can tell, most of that commit is still fine. You
> Jens> want bdev_get_integrity() in blkdev.h, the 3 other moves and the
> Jens> unused bdev_get_tag_size() do not look like they are being used
> Jens> by this patch set.
> 
> bdev_get_integrity() and bdev_get_tag_size() are being used by
> stacking drivers and filesystems to prepare I/O.  It's correct that
> none of the in-tree stuff currently uses bdev_get_tag_size().  That's
> coming with the btrfs support.  If you want to pull that out for now
> and have me put that back later in that's ok.  Just adds another
> two-stage merge dependency for a later cycle.

Well, I would not have added it in the first place, but it was there. I
already did the bdev_get_integrity() addon instead of the revert, so
lets please just keep it at that.

> bdev_integrity_enabled() and blk_integrity_tuple_size() are only being
> used from within bio-integrity.c and can move there.  I originally put
> them in blkdev.h because they are block device functions and not bio
> ditto.
> 
> Want me to submit a new patch shuffling bdev_get_integrity() back
> where it came from?

Do we need any on top of current for-2.6.28?

I'll apply your series with the modified patch #5, it'll probably need a
hand edit or two since I didn't revert the commit in question, but
should be trivial to resolve.


-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: neilb@suse.de, agk@sourceware.org, linux-kernel@vger.kernel.org,
	dm-devel@redhat.com
Subject: Re: Block integrity patches for 2.6.28
Date: Thu, 2 Oct 2008 18:29:56 +0200	[thread overview]
Message-ID: <20081002162955.GI19428@kernel.dk> (raw)
In-Reply-To: <yq1wsgrgl0o.fsf@sermon.lab.mkp.net>

On Thu, Oct 02 2008, Martin K. Petersen wrote:
> >>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:
> 
> Jens> As far as I can tell, most of that commit is still fine. You
> Jens> want bdev_get_integrity() in blkdev.h, the 3 other moves and the
> Jens> unused bdev_get_tag_size() do not look like they are being used
> Jens> by this patch set.
> 
> bdev_get_integrity() and bdev_get_tag_size() are being used by
> stacking drivers and filesystems to prepare I/O.  It's correct that
> none of the in-tree stuff currently uses bdev_get_tag_size().  That's
> coming with the btrfs support.  If you want to pull that out for now
> and have me put that back later in that's ok.  Just adds another
> two-stage merge dependency for a later cycle.

Well, I would not have added it in the first place, but it was there. I
already did the bdev_get_integrity() addon instead of the revert, so
lets please just keep it at that.

> bdev_integrity_enabled() and blk_integrity_tuple_size() are only being
> used from within bio-integrity.c and can move there.  I originally put
> them in blkdev.h because they are block device functions and not bio
> ditto.
> 
> Want me to submit a new patch shuffling bdev_get_integrity() back
> where it came from?

Do we need any on top of current for-2.6.28?

I'll apply your series with the modified patch #5, it'll probably need a
hand edit or two since I didn't revert the commit in question, but
should be trivial to resolve.


-- 
Jens Axboe


  reply	other threads:[~2008-10-02 16:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-01  7:38 Block integrity patches for 2.6.28 Martin K. Petersen
2008-10-01  7:38 ` Martin K. Petersen
2008-10-01  7:38 ` [PATCH 1/7] block: Introduce integrity data ownership flag Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-01  7:38 ` [PATCH 2/7] block: Fix double put in blk_integrity_unregister Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-01  7:38 ` [PATCH 3/7] block: Switch blk_integrity_compare from bdev to gendisk Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-01  7:38 ` [PATCH 4/7] block: gendisk integrity wrapper Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-01  7:38 ` [PATCH 5/7] block: Find bio sector offset given idx and offset Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-01  8:10   ` Jens Axboe
2008-10-02  2:42     ` Martin K. Petersen
2008-10-02  2:42       ` Martin K. Petersen
2008-10-02 17:07       ` Jens Axboe
2008-10-01  7:38 ` [PATCH 6/7] dm: Add support for data integrity to DM Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-01  7:38 ` [PATCH 7/7] md: Add support for data integrity to MD Martin K. Petersen
2008-10-01  7:38   ` Martin K. Petersen
2008-10-02 10:56 ` Block integrity patches for 2.6.28 Jens Axboe
2008-10-02 13:54   ` Martin K. Petersen
2008-10-02 16:29     ` Jens Axboe [this message]
2008-10-02 16:29       ` Jens Axboe

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=20081002162955.GI19428@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=agk@sourceware.org \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.