public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	linux-kernel@vger.kernel.org, jmerkey@timpanogas.org
Subject: Re: Block I/O Enchancements, 2.5.1-pre2
Date: Wed, 28 Nov 2001 14:35:51 +0100	[thread overview]
Message-ID: <20011128143551.U23858@suse.de> (raw)
In-Reply-To: <15364.3457.368582.994067@gargle.gargle.HOWL> <Pine.LNX.4.33.0111271701140.1629-100000@penguin.transmeta.com> <20011127183418.A812@vger.timpanogas.org>
In-Reply-To: <20011127183418.A812@vger.timpanogas.org>

On Tue, Nov 27 2001, Jeff V. Merkey wrote:
> On Tue, Nov 27, 2001 at 05:04:46PM -0800, Linus Torvalds wrote:
> > 
> > On Wed, 28 Nov 2001, Paul Mackerras wrote:
> > >
> > > Is there a description of the new block layer and its interface to
> > > block device drivers somewhere?  That would be helpful, since Ben
> > > Herrenschmidt and I are going to have to convert several
> > > powermac-specific drivers.
> > 
> > Jens has something written up, which he sent to me as an introduction to
> > the patch. I'll send that out unless he does a cleaned-up version, but I'd
> > actually prefer for him to do the sending. Jens?
> > 
> > 		Linus
> > 
> 
> 
> Linus/Jens,
> 
> I've just completed my review of submit_bio and the changes to 
> generic_make_request and I have some questions for whomever
> can answer.
> 
> 1.  The changes made to submit_bh indicate I can now send long 
> chains of variable block size requests to the I/O layer similiar
> to the capability of Windows 2000 and NetWare I/O subsystems.

Yes, you can build generically a single I/O unit that spans up to 256
pages. If you bypass the bio_alloc/bvec_alloc mechanism, the sky is the
limit. Beware that a really big bio may need to be split up in the end
for devices that can't handle them that big.

> 2.  The elevator layer is merging these requests, and making a 
> single sweep request for contiguous sector runs.

Like always, yes.

> 3.  In theory, I should be able to support page cache capability
> for NWFS and possibly NTFS in Linux the way these wierd non-Unix 
> OS's work.

Maybe :-)

> 4.  This interface may **NOT** support non-block aligned requests
> across all the drivers.  I also need to be able to submit a 
> request chain 512-2048-512-1024-4096 where the first IO requested
> may by on a non-block aligned boundry.  i.e.  Device is configured
> for 1024 byte blocks, I start the request as 512 @ LBA 1 -> 1024 @ LBA 2, 
> etc.  The code looks like it will work.

As long as the smallest unit above is at least the size of the hardware
sector on the target, it should be ok.

> I would love to test this wonderful code and will hopefully this evening,
> however, all the SCSI drivers appear to be broken, as well as the 
> 3Ware. :-)

Well not all, but many. I only converted stuff I could personally test,
basically, plus a bit more. Usually converting a SCSI driver is not a
lot of work, please see the changes to sym/sym2 etc in the pre2 patch.

-- 
Jens Axboe


  parent reply	other threads:[~2001-11-28 13:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-27 20:44 2.5.1-pre2 does not compile f5ibh
2001-11-27 20:50 ` Linus Torvalds
2001-11-27 22:02   ` Paul Mackerras
2001-11-28  1:04     ` Linus Torvalds
2001-11-28  1:34       ` Block I/O Enchancements, 2.5.1-pre2 Jeff V. Merkey
2001-11-28  1:45         ` Jeff Garzik
2001-11-28  1:55           ` Jeff V. Merkey
2001-11-28  2:32             ` Jeff Garzik
2001-11-28  3:38               ` Linus Torvalds
2001-11-30  2:19                 ` Daniel Phillips
2001-11-30 12:21                   ` Hans Reiser
     [not found]                     ` <15367.32910.275973.287742@laputa.namesys.com>
2001-12-01  9:31                       ` [reiserfs-dev] " Hans Reiser
2001-11-28 10:17               ` Martin Dalecki
2001-11-28 13:35         ` Jens Axboe [this message]
2001-11-28 17:29           ` Jeff Merkey
2001-11-28  6:58       ` 2.5.1-pre2 does not compile Jens Axboe
2001-11-28 12:20       ` bio write-up (was: Re: 2.5.1-pre2 does not compile) Jens Axboe
2001-11-28 23:31       ` 2.5.1-pre2 bio offset by one error in VIA IDE Anton Altaparmakov
2001-11-28 23:55         ` Andreas Dilger
2001-11-29  1:07         ` Anton Altaparmakov
2001-11-30  1:53     ` 2.5.1-pre2 does not compile Daniel Phillips
2001-11-27 22:09   ` Christoph Hellwig
2001-11-27 22:22     ` onboard ethernet/sound on Soyo SY-K7V? Dax Kelson
2001-11-27 22:47       ` François Cami
2001-11-27 22:57       ` Jeff Garzik
2001-11-27 22:29     ` 2.5.1-pre2 does not compile Robert Love
2001-11-28  0:29     ` Linus Torvalds
2001-11-28 12:55       ` Christoph Hellwig
2001-11-28 16:26         ` Andreas Dilger
2001-11-28 16:42           ` Christoph Hellwig
2001-11-28 16:39             ` Martin Dalecki
2001-11-28 17:27             ` Andreas Dilger
2001-11-28  0:40   ` Andre Hedrick

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=20011128143551.U23858@suse.de \
    --to=axboe@suse.de \
    --cc=jmerkey@timpanogas.org \
    --cc=jmerkey@vger.timpanogas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox