Subject: Re: SCSI MMC device abstraction and UDF patch for review
To: None <>
From: YAMAMOTO Takashi <>
List: tech-kern
Date: 12/27/2005 07:22:05
> > >
> > 
> > - 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.