--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--