Subject: Re: RFC (reassign)buf and carvinf up buffers (was Re: SCSI MMC device abstraction and UDF patch for review)
To: Reinoud Zandijk <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 12/29/2005 09:58:51
Content-Type: text/plain; charset=us-ascii
On Thu, Dec 29, 2005 at 03:17:58PM +0100, Reinoud Zandijk wrote:
> Dear Bill,
> On Wed, Dec 28, 2005 at 09:45:54PM -0800, Bill Studenmund wrote:
> > > I'll try out the reassign though i wonder what problems and complexit=
> > > might arise from mismatched vop_strategy() buffer sizes and disc logi=
> > > block sizes. vop_strategy() now requests buffers upto say 64 kb/piece=
> > > the logical block size might be 2kb. Each part of 2kb can/could be st=
> > > somewhere else on disc. Normally a VOP_BMAP could determine the exten=
> > > could take in one go but looking up such information can be costly.
> > vop_strategy() makes requests sized as the file system wants. To be=20
> > perfectly honest, if your 2k logical blocks are not next to each other,=
> > you shouldn't be issuing a 64k request. Or at least it should be broken=
> > before the vop_strategy() level.
> That implies having a VOP_BMAP() figuring this out. Since UDF can't use a=
> VOP_BMAP this way (due to write shuffling) it would mean that VOP_BMAP=20
> needs to distinguish between read and write requests and for read-request=
> try to figure out how much it can read in one go... quite expensive and=
> locking trouble prone.
This does not imply VOP_BMAP() figuring this out.
The file system decides what data goes into what buffers. The file system=
knows what blocks are where. Thus you don't have to figure all of this out=
in the middle of your strategy routine, you can figure it out when you=20
make the buffers in the first place.
More directly, you SHOULD figure it out before your strategy routine.
> > As such, I don't think we need this support to do what you suggest. I c=
> > think of other reasons I would like it, but the file system should only=
> > issuing requests (to this level of the kernel) that can make it to the
> > disk in contiguous blocks.
> Remember, UDF (and LFS AFAIK) uses the vnode's of the filingsystem to=20
> buffer its data. A VOP_STRATEGY() read request of an extent is thus an=20
> extent read/write on the file/vnode and has nothing to do with disc mappi=
> IMHO. Disc sheduling is done at the device node anyway; not on the=20
> file/vnode's node. At device level i agree with you though.
No, a VOP_STRATEGY() call does NOT represent a read/write that has nothing=
to do with disk mapping, it represents a read or write of a buffer. Said=20
buffer represents an extent on disk. One extent. If you have multiple=20
extents in your transfer, you are dealing with multiple buffers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----