On Tue, 4 Jun 2002, Greywolf wrote:

> On Tue, 4 Jun 2002, Bill Studenmund wrote:
> # On Mon, 3 Jun 2002, Greywolf wrote:
> # > Question:
> # >
> # > What do we do about media that can have really wacky sector sizes (such
> # > as CD-ROM devices which purportedly support 2136 bytes/sector or some
> # > such oddness, I forget the actual size)?
> #
> # We don't know.
> #
> # The problem is that with UBC, the VM cache is the main data cache, and it
> # is in terms of VM pages. 2136 doesn't fit into the size of a VM page very
> # well, so we're hosed. :-|
>
> One word:  Padding.
>
> Fit as many onto a page as you can, then pad out what doesn't fit on the
> last record, and do as we do for files:  return an actual length of data
> on the page (up to the start of the pad).

That would be one solution. And it might be the best.

Another option might be to make some sort of vm paging device that used
larger-than-one page lumps. Mainly to consolidate padding. 4k will hold
one CD sector, 8k will hold 3, but 16k will hold 7, and 32k will hold 15.

It really depends on what we want to do with the pages. If we want a
stream that can be read, then we don't want any padding, and that means
copying.

> Now before anyone has a snide (or more impolite) reply:
>
> 1.  No, contrary to popular opinion, I am _not_ high on crack.

No, you're describing trying to merge two designs that don't merge well.

> 2.  No, I am not "hunting bear".

?? I'm not familiar with this term.

> 3.  I am aware that this is a potentially very bloating and non-trivial
> 	implementation detail.
> 4.  This is a "nice to have" thing as opposed to a "we must do this or
> 	die" thing.
>
> That said...
>
> It seems as though many software companies use the 2352 (thanks, Mouse!)
> CDDA sector size as copy protection.  Now, I'm not going to claim that we
> should be able to copybreak anything, but we should be able to read just
> about any sector size.

It would be nice. I think though that the best thing to do is wait for
someone to come along with an application (or interest in spending time
working on it) and see what we can do. :-)

> I seem to recall some weirdness like 540 byte/sector hard drives as well.
> Some very old SMD drives (do NOT attempt to carry one by yourself -- you
> will end up with a hernia (ask me how I know)) will also support varying
> sector sizes, but those are all shift-multiples of 512 (the Pyramid OS
> (OSx, was it?) demanded that all drives be hard-formatted to 2048
> bytes/sector), so that's obviously being taken into consideration.
>
> Anything that looks to "hose us", though, should probably be examined in
> serious detail.  If an implementation can be done without too much of a
> space/performance issue, it might not be a bad idea.  Obviously, if
> the gain:effort is too low, it won't be worth the time.
>
> Thoughts?

I like the idea, we just need a better idea of the exact application.

Take care,

Bill