Subject: Re: RFC (reassign)buf and carvinf up buffers (was Re: SCSI MMC device abstraction and UDF patch for review)
To: Bill Studenmund <wrstuden@netbsd.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 12/29/2005 15:17:58
--GvXjxJ+pjyke8COw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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 complexity
> > might arise from mismatched vop_strategy() buffer sizes and disc logicl
> > block sizes. vop_strategy() now requests buffers upto say 64 kb/piece and
> > the logical block size might be 2kb. Each part of 2kb can/could be stored
> > somewhere else on disc. Normally a VOP_BMAP could determine the extent it
> > 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
> 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 up
> 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
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.
> As such, I don't think we need this support to do what you suggest. I can
> think of other reasons I would like it, but the file system should only be
> 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
buffer its data. A VOP_STRATEGY() read request of an extent is thus an
extent read/write on the file/vnode and has nothing to do with disc mapping
IMHO. Disc sheduling is done at the device node anyway; not on the
file/vnode's node. At device level i agree with you though.
Take care,
Reinoud
--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
iQEVAwUBQ7PwD4KcNwBDyKpoAQIT/QgAvTinrHNZQ4U1YUMmgGuJhQx7zIhzZzyZ
RWEfQA3CsXEikdEvJhOa6FrRShjR5MankAf+Pf53quxfHZNZ91DxK4vo4Hey2ymA
oKOKAhMH54MTHh7W1ORFOCIqi+rAla8PieEc5XHtYBWbF31tBxSoByMG24vvxRoV
2SEYEYkO422aguZexTd3XBTHLfHfGxvPTypq2jKLyNZwygZ9cL4SeY0AlSLcPdBb
Oj6t/2A8s8EQc8v5e84mLHLeYG7cBC4s7WL1VdK1/mq7/HbgAnnenaHIJTr/ycAZ
0G6XbUh38b9LfZ8vHOB0uYwpg5fPCLoTveY06kJnV786baZN7Qhbhw==
=zwuc
-----END PGP SIGNATURE-----
--GvXjxJ+pjyke8COw--