From: Jeff Garzik <jeff@garzik.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org,
axboe@kernel.dk, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] osdblk: a Linux block device for OSD objects
Date: Fri, 03 Apr 2009 06:14:02 -0400 [thread overview]
Message-ID: <49D5E16A.80104@garzik.org> (raw)
In-Reply-To: <1238722324.13399.25.camel@mulgrave.int.hansenpartnership.com>
James Bottomley wrote:
>> + 1) Map a Linux block device to an existing OSD object.
>> +
>> + In this example, we will use partition id 1234, object id 5678,
>> + OSD device /dev/osd1.
>> +
>> + $ echo "1234 5678 /dev/osd1" > /sys/class/osdblk/add
>> +
>> +
>> + 2) List all active blkdev<->object mappings.
>> +
>> + In this example, we have performed step #1 twice, creating two blkdevs,
>> + mapped to two separate OSD objects.
>> +
>> + $ cat /sys/class/osdblk/list
>> + 0 174 1234 5678 /dev/osd1
>> + 1 179 1994 897123 /dev/osd0
>
> This is a slight violation of the one piece of data per sysfs file
> rule ... might it not be better as a file named <partid>-<objid> linking
> to the osd device location in sysfs?
Yeah... I leaned more towards a consolidated table, as it was
elegantly implemented in just a few lines of code, including locking :)
>> + The columns, in order, are:
>> + - blkdev unique id
>> + - blkdev assigned major
>> + - OSD object partition id
>> + - OSD object id
>> + - OSD device
>> +
>> +
>> + 3) Remove an active blkdev<->object mapping.
>> +
>> + unsigned long obj_id;
>> + char osd_path[0];
>> +};
>> +
>> +static struct class *class_osdblk; /* /sys/class/osdblk */
>> +static struct mutex ctl_mutex; /* Serialize open/close/setup/teardown */
>> +static struct osdblk_device *osdblk_devs[OSDBLK_MAX_DEVS];
>
> Might it not be better to do this as a linked list on the private dev
> structure instead? This only works if you have one entry
> in /sys/class/osdblock per device because now you have a device private
> pointer to hang it off
converted to list
>> +static int osdblk_get_free_req(struct osdblk_device *osdev)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < OSDBLK_MAX_REQ; i++) {
>> + if (!osdev->req[i].rq)
>> + return i;
>> + }
>
> Rather than using a static list of outstanding requests, I think you
> could probably use the block tag handling infrastructure for all of this
converted to use blk-tag.c gadgetry
Thanks for the review!
Jeff
next prev parent reply other threads:[~2009-04-03 10:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 1:54 [PATCH] osdblk: a Linux block device for OSD objects Jeff Garzik
2009-04-02 2:05 ` Jeff Garzik
2009-04-02 12:26 ` Boaz Harrosh
2009-04-02 16:46 ` Jeff Garzik
2009-04-03 9:38 ` Jeff Garzik
2009-04-05 10:22 ` Boaz Harrosh
2009-04-03 1:32 ` James Bottomley
2009-04-03 10:14 ` Jeff Garzik [this message]
2009-04-03 9:49 ` Jens Axboe
2009-04-03 9:58 ` Jeff Garzik
2009-04-05 10:18 ` Boaz Harrosh
2009-04-08 1:29 ` Jeff Garzik
2009-04-08 5:45 ` Jens Axboe
2009-04-08 6:02 ` Jeff Garzik
2009-04-08 6:08 ` Jens Axboe
2009-04-07 7:26 ` Pavel Machek
2009-04-07 22:53 ` [PATCH v2] " Jeff Garzik
2009-04-10 11:48 ` [PATCH 1/3] block/blk-map.c: blk_rq_append_bio should ensure it's not appending a chain Jeff Garzik
2009-04-10 11:49 ` [PATCH 2/3] osd_initiator: support bio chains Jeff Garzik
2009-04-10 11:50 ` [PATCH 3/3 v3] osdblk: a Linux block device for OSD objects Jeff Garzik
2009-04-27 15:59 ` Boaz Harrosh
2009-04-27 18:24 ` Jens Axboe
2009-04-28 9:40 ` Boaz Harrosh
2009-04-27 16:02 ` [PATCH 2/3] osd_initiator: support bio chains 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=49D5E16A.80104@garzik.org \
--to=jeff@garzik.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=linux-fsdevel@vger.kernel.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 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.