Subject: Re: Supporting sector size != DEV_BSIZE -- patches
To: Bill Studenmund <wrstuden@netbsd.org>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 06/04/2002 09:13:06
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).

Now before anyone has a snide (or more impolite) reply:

1.  No, contrary to popular opinion, I am _not_ high on crack.
2.  No, I am not "hunting bear".
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.

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?

# Take care,
#
# Bill


				--*greywolf;
--
NetBSD: the Berkeley redemption.