> > > ftp://ftp.NetBSD.org/pub/NetBSD/misc/reinoud/src-diffs-udf.20051222.gz
> > 
> > - it seems to do double-caching.  ie. at both of udf and block device.
> >   is it intended?
> 
> Yes and no. For UDF it is better to use caching in udf since blocks can 
> move around esp. on recordables; every disc write changes the location of 
> the block so its easier to have it cached on the file's vnode on its 
> logical block instead of a moving buffer on disc. Setting B_NOCACHE in the 
> buffers passed to the block device is prolly advisable yes.
> 
> The two stubs for reading are to be integrated in a safeguard mechanism 
> that orders read and write requests in such a way that it doesn't inflict 
> adressing issues due to percularities in writing to recordables.

it also involves redundant memcpy, which can't be solved by B_NOCACHE.

> > - "bp->b_lblkno = bp->b_blkno;" in udf_strategy is only for printf?
> 
> not intentionally. During developement of the code i read that when the 
> logical block number wasn't equal to the blocknumber that it was then 
> allready translated with VOP_BMAP and thus could be directed to the 
> device's strategy routine. This might be in imported FS though. To assure 
> that *all* reads and writes are passed trough UDF i made this explicit 
> assurance that all buffers are allways BMAP'd and thus passed trough UDF's 
> strategy. This might be based on old or incomplete information but i'd 
> rather be safe in this than get surprised later by other parts of the FS 
> stack making this assumption.

i'd say "safe" == "hide bugs".

> > - is udf sector size ("lb_size" in udf_strategy)
> >   always smaller than or equal to page size?
> 
> no... lb_size can be every multiple of 512 in the UDF spec though trough 
> limitations in NetBSD the code only accepts lb_sizes in powers of 2. See 
> the check in udf_mount(). Most common are 512 and 2048 in practice. Other 
> values are more to safeguad implementations to make assumptions on this. 
> Would/could this pose problems ?

if it's larger than page size, page-aligned i/o can't be be represented
in the unit.

YAMAMOTO Takashi