Re: [9fans] Fs64 file server, partition boundaries out of range

[geoff@plan9.bell-labs.com]

I believe Charles wrote the original version of what is now
dowormcopy() and I probably modified it; Nigel may have also.  It
copes with real and fake worms.  On a fake worm, the block-allocation
bitmap is at the end of the file system, but all blocks can be read.

On a real worm, only already-written blocks can be read and there is
no allocation bitmap (or at least none visible outside the jukebox
hardware).  Because the file server kernel gradually extends the upper
limit of blocks it will allocate on the worm, there will tend to be
both written and unwritten blocks just before the current nominal end
of the file system (but the end is increased when cwgrow() is called).
After the current end there should only be unwritten blocks, and
almost all of the blocks before it should be written.

All sizes are in blocks of RBUFSIZE bytes.  writtensize() gets the
device's size from devsize(), which calls fwormsize() for fake worms
or cwsize() for real ones.  cwsize() just gets the current end of the
file system from the cache device, where it's conveniently stored.
fwormsize() subtracts the size of the allocation bitmap from the size
of the underlying device.  writtensize() works backward from the end
of the device, using the size returned by devsize() as its nominal
size, reading blocks until it succeeds.  This should be pretty quick;
for fake worms, fwormread() just consults the allocation bitmap to see
if a block is allocated and thus readable, so writtensize() will see a
long series of failed getbuf() attempts before reading the last
allocated block before the allocation bitmap.  Real worms are similar,
but starting at the cache's notion of where the file system currently
ends will be much closer to the last-written block than starting at
the end of the non-bitmap fake worm device, so the backward scan will
be short.