On Aug 27, 2005, at 10:56 AM, Reinoud Zandijk wrote:

> HFS+ on CD? i found one recently but thought it was such an oddity.
> Aparently not :) I found the disc to be formatted with HFS+ and UDF  
> and
> found the UDF part to be corrupt.

HFS+ on CDs is certainly a common thing among Mac users. HFS+ and UDF  
together sounds like it was probably made in Roxio Toast, which lets  
you create hybrid Mac/PC disks. But now you can read the HFS+ part on  
NetBSD. :)

> not nessisarily 2k! though mostly used when writing CD's in  
> streaming and
> packet mode. I dont know about HFS+ but the UDF filingsystem  
> supports every
> multiple of 512 bytes as sector size though allways the same as the  
> device
> has, and yes 7680 bytes/sector is valid as is 1536 :-S

HFS+ is actually almost independent of sector size, and I don't  
believe it places any limitations on it. So yeah, 7680 would work, as  
would 31337. ;) For best performance, however, the sector size should  
evenly divide into the HFS+ block size, which is a power of 2 and at  
least 512 bytes.

> I wonder how i can implement sector sizes bigger than MAXBSIZE  
> (normally
> around 4k AFAIK) with normal bread and bwrite calls though.

The quirkiness in bread() isn't related to MAXBSIZE; to read a chunk  
larger than MAXBSIZE from the disk, you simply call bread multiple  
times. The real problem lies in the way you specify the arguments you  
pass it. bread() not only requires the size parameter to be an  
integral multiple of the sector size, but also requires the block  
number to be on a boundary of that sector size -- and yet be given as  
an integral multiple of DEV_BSIZE! I wrote a wrapper around bread()  
which takes care of these idiosyncrasies, so you can call it with any  
arbitrary length and offset and it will call bread() enough times and  
with the correct arguments. You can find it in my SoC code in hfs/ 
hfsp/hfsp_subr.c; the function name is hfsp_pread().


Take care,
Yevgeny