All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	open-osd mailing-list <osd-dev@open-osd.org>,
	Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH 0/2 version 4] osdblk: a Linux block device for OSD objects
Date: Thu, 28 May 2009 18:31:00 -0400	[thread overview]
Message-ID: <4A1F10A4.30601@garzik.org> (raw)
In-Reply-To: <4A1B9DA4.2080304@panasas.com>

Boaz Harrosh wrote:
> On 05/22/2009 01:41 AM, Jeff Garzik wrote:
>> Boaz Harrosh wrote:
>>> I'm posting for review a new version of the osdblk driver. What's new?
>>>
>>> * Once block/for-2.6.31 and all pending osd patches hit mainline. this new version
>>>   is ready for submission.
>>>   - The relevant osd patches have been posted on the mailing list, but I'll send an orderly
>>>     set for scsi-misc and scsi-post-merge on Sunday.
>>>   - All the prerequisite block patches are already in Jens's tree.
>>>
>>> * Below is the diff from Jeff's last version of the patch. these things have changed:
>>>  {SQUASHME: osdblk} Block and OSD Api fixups and bug fixes
>>>
>>>  - Block API changes from Tejuns revamps
>>>  - OSD Api changes for supporting bio-chaining
>>>  - do_flush requests do not need bio clonning
>>>    (And might not have any so prevent such a crash)
>>>  - osdblk_make_credential is here to stay
>>>  - Use bio_kmalloc and avoid the bio_alloc dead/live locks.
>>>    TODO: Split request into smaller chunks if allocations fail.
>>>  - Only use __GFP_WAIT on first bio allocation. (Not relevant since
>>>    __GFP_WAIT is not used)
>>>
>>> * Added an extra patch:
>>>  - [PATCH 2/2] osdblk: Adjust queue limits to lower device's limits
>>>
>>> This is ontop of the post-merge tree. Jeff? will you push this driver
>>> through your tree?
>>>
>>> What is left is to bang some serious testing on this driver. I'll do
>>> that next.
>> The changes look reasonable to me...   if you wanted to get it into your 
>> tree and push it with other OSD stuff, that would be fine to me.
>>
>> I think you are in a better position to deal with all the pre-req's, and 
>> in a better position to test osdblk more completely.
>>
>> Have you messed around with the user tools yet?  osdblk needs a tool 
>> that creates an OSD object of a specified size, etc.
>>
>> 	Jeff
>>
> 
> Thanks Jeff.
> 
> So is this a:
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>

Yes, if it works in your testing.  Please make sure the commit is "From: 
Jeff Garzik" as well, thanks.


> But please send me a commit log, or should I scribble one?

Just a one-line "add osdblk, block driver for OSD objects" should be fine.


> About the user-mode tool: Sorry I'm so very busy with the pNFS
> layout driver and export that I do not have time for it right now.
> 
> For testing I just use exofs, create a file and dd to some offset to
> make it of some size. Very very stupid I know, but easy. (The obj-id
> I can guess as I know the code)
> 
> Tell me if you absolutely need a fast hack that just takes the ids
> and size and creates one object, for now.

Some simple tool like that is needed; a user shouldn't have to know 
exofs just to be able to use osdblk :)

If nothing else appears, I'll whip something up before 2.6.31, but I was 
of course hoping to talk you into it, since you could do it faster and 
better than me :)

	Jeff





  reply	other threads:[~2009-05-28 22:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-21 14:06 [PATCH 0/2 version 4] osdblk: a Linux block device for OSD objects Boaz Harrosh
2009-05-21 14:09 ` [PATCH 1/2 " Boaz Harrosh
2009-05-21 14:11 ` [PATCH 2/2] osdblk: Adjust queue limits to lower device's limits Boaz Harrosh
2009-05-21 22:41 ` [PATCH 0/2 version 4] osdblk: a Linux block device for OSD objects Jeff Garzik
2009-05-26  7:43   ` Boaz Harrosh
2009-05-28 22:31     ` Jeff Garzik [this message]
2009-05-31  9:50       ` Boaz Harrosh
2009-06-10 12:52         ` Jeff Garzik
2009-06-10 13:33           ` Boaz Harrosh

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=4A1F10A4.30601@garzik.org \
    --to=jeff@garzik.org \
    --cc=bharrosh@panasas.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=osd-dev@open-osd.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 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.