Help writing block driver for large removable media

[Jeff Scofield]

We have built a block driver for removable media (in fact, a
magneto-optical disk) under SunOS 4.0.3, but have encountered a
difficulty.  I'm hoping that an expert on the net can help.  Here are the
relevant facts.  (#3 is closer to an educated guess.)

1.  There are several types of cartridges for our disk, with different
    sizes.  And of course each cartridge can have its own partition sizes.

2.  A block driver must provide an entry point that returns the number of
    blocks in a given partition.  I'll call it ``size().''

3.  Once the kernel has called the size() entry point, it appears to cache
    the partition size *forever* (until reboot).  In other words, the kernel
    assumes that the returned size value is permanently valid.

4.  But there *is* no permanently valid size for our device.  A user can
    remove the cartridge and replace it with another of a different size (or
    with different partition sizes).

This seems to offer us the dismal choice among the following:

a.  Don't allow the cartridges to be partitioned, and treat them all as
    the same size (wasting space on the larger ones).

b.  Require users to reboot every time they want to change to a different
    cartridge!

c.  Return a false (i.e., essentially infinite) value from the size()
    entry point.

The first two are fairly obviously unacceptable.  We have tried the third
one and are not particularly happy with the results.  (You don't want to
hear about it.)

It would seem that Sun must have, at some time, imagined writing a block
driver for a device with different-sized removable media.   A floppy disk
might be an example.  Furthermore, you might imagine that Sun would want
to allow users to repartition a disk without rebooting before using it.

Can anyone shed any light on this difficulty?  Is there, for example, a
way (from within a block driver) to get the kernel to give up on its
cached size information for a disk partition?

Thanks in advance for any help.

Jeff Scofield, Cedar River Software, Seattle  WA
    cedar!jeff at beaver.cs.washington.edu
    ...!uw-beaver!cedar!jeff