--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Dec 29, 2005 at 09:58:51AM -0800, Bill Studenmund wrote:
> > 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.
> 
> 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 
> make the buffers in the first place.
> 
> More directly, you SHOULD figure it out before your strategy routine.

Since UDF uses genfs, genfs decides the number of blocks to request by the 
`runp' variable set by its VOP_BMAP() call to the filingsystem. Since UDF's 
bmap is a 1:1 translation it allways returns the maximum runlength with

   *runp = MAXPHYS / lb_size;

to make full use of long extents to read to reduce the number of 
transactions as much as possible. Note that this isn't happening yet but 
thats the idea behind it. If i otoh return 0 or 1 i get lb_size or 
2*lb_size. So prolly i'll have to substract 1 from the *runp assignment :)

> 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 
> buffer represents an extent on disk. One extent. If you have multiple 
> extents in your transfer, you are dealing with multiple buffers.

true the read or write of a buffer that is created by genfs. So i allways 
have to return a runlength of one then and loosing all hope on multi-sector 
reads?

Regards,
Reinoud

--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ7RLVoKcNwBDyKpoAQLv1ggAlHLkbFvZdeQZ4b0Sgd7I0AGn00nt1kL7
8Eg8+lEF1HuU/MffCc1fsvJe95t9qgiye3oeN4OqRwwbYkHRR7pSPMOQ1ZpO2Dz4
+0E9y076ZL2mJneO5DfHlZYVCvmG2vx5JSSgVLSo0L7PBZrFZT+/h3X0eYetCdDE
i0tVIdB6UyJNYOoIk5vtU+yRIqGUWjBhO/3cVT8G5i7TwuMrizz55RQeXtGKUTS0
WdSlE7tKwsLv+Rf0yCBF1DuiPOiFlbBC+j9S7wdDO4dYfqGX/rW/mMVAiLvmkxrX
dVONS0iqrPsQ+5PlNa1jUPWuxIvH/iECOeTFlgxDWQAuYeV6ccUo5g==
=uswM
-----END PGP SIGNATURE-----

--sdtB3X0nJg68CQEu--