On Mon, 16 Feb 2009 10:49:39 +0200
Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> FUJITA Tomonori wrote:
> > On Mon, 9 Feb 2009 15:12:09 +0200
> > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> >
> >> This patch includes osd infrastructure that will be used later by
> >> the file system.
> >>
> >> Also the declarations of constants, on disk structures,
> >> and prototypes.
> >>
> >> And the Kbuild+Kconfig files needed to build the exofs module.
> >>
> >> Signed-off-by: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
> >> ---
> >> fs/exofs/Kbuild | 30 +++++++
> >> fs/exofs/Kconfig | 13 +++
> >> fs/exofs/common.h | 181 +++++++++++++++++++++++++++++++++++++++++
> >> fs/exofs/exofs.h | 139 ++++++++++++++++++++++++++++++++
> >> fs/exofs/osd.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> 5 files changed, 593 insertions(+), 0 deletions(-)
> >> create mode 100644 fs/exofs/Kbuild
> >> create mode 100644 fs/exofs/Kconfig
> >> create mode 100644 fs/exofs/common.h
> >> create mode 100644 fs/exofs/exofs.h
> >> create mode 100644 fs/exofs/osd.c
> >
> >> +static void _osd_read(struct osd_request *or,
> >> + const struct osd_obj_id *obj, uint64_t offset, struct bio *bio)
> >> +{
> >> + osd_req_read(or, obj, bio, offset);
> >> + EXOFS_DBGMSG("osd_req_read(p=%llX, ob=%llX, l=%llu, of=%llu)\n",
> >> + _LLU(obj->partition), _LLU(obj->id), _LLU(bio->bi_size),
> >> + _LLU(offset));
> >> +}
> >> +
> >> +#ifdef __KERNEL__
> >
> > Hmm?
> >
>
> Yep, this file also complies in user mode.
Even if you do, it's a good thing to add __KERNEL__ to fs/*.c?
> >> +static struct bio *_bio_map_pages(struct request_queue *req_q,
> >> + struct page **pages, unsigned page_count,
> >> + size_t length, gfp_t gfp_mask)
> >> +{
> >> + struct bio *bio;
> >> + int i;
> >> +
> >> + bio = bio_alloc(gfp_mask, page_count);
> >> + if (!bio) {
> >> + EXOFS_DBGMSG("Failed to bio_alloc page_count=%d\n", page_count);
> >> + return NULL;
> >> + }
> >> +
> >> + for (i = 0; i < page_count && length; i++) {
> >> + size_t use_len = min(length, PAGE_SIZE);
> >> +
> >> + if (use_len !=
> >> + bio_add_pc_page(req_q, bio, pages[i], use_len, 0)) {
> >> + EXOFS_ERR("Failed bio_add_pc_page req_q=%p pages[i]=%p "
> >> + "use_len=%Zd page_count=%d length=%Zd\n",
> >> + req_q, pages[i], use_len, page_count, length);
> >> + bio_put(bio);
> >> + return NULL;
> >> + }
> >> +
> >> + length -= use_len;
> >> + }
> >> +
> >> + WARN_ON(length);
> >> + return bio;
> >> +}
> >
> > 1) exofs builds bios by hand.
> > 2) exofs passes bio to OSD SCSI ULD.
> >
> > As a result, exofs and OSD SCSI ULD need to know the internal of bio,
> > that is, you reinvent the bio handling infrastructure, as pointed out
> > in another thread in scsi-ml.
> >
> > _bio_map_pages is called where the VFS passes an array of a pointer to
> > a page frame.
> >
> > Why can't you simply pass the array to OSD SCSI ULD? Then OSD SCSI ULD
> > can use the block layer helper functions to build a request out of
> > pages without knowing the internal of bio.
> >
> >
>
> Because actually this code is wrong and temporary and will change soon.
> At vfs write_pages I do not get a linear array of page pointers but a
> link-list of pages. This will not fit any current model.
Then, why can't you pass a link-list of pages?
> Also looking
> ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio
> is the perfect collector for memory information in this situation.
You will add such features to exofs, handling multiple devices
internally?
> exofs is not the first and only file system who is using bios. Proof of
> the matter is that block exports a bio submit routine.
Seems that exofs just passes pages and the ULD sends a SCSI command
including these pages. I don't see how exofs needs to handle bio
directly.
> As I said on the other thread, I could live without it for now, for a short while,
> but I will regret it badly and it will hurt performance in the long run.
>
> <snip>
>
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
