From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
From: Gregory Pavelcak <g.pavelcak@comcast.net>
Subject: Re: [9fans] Fs64 file server, partition boundaries out of range 
In-Reply-To: Your message of "Sat, 05 Aug 2006 19:13:05 EDT."
	<cdc21564dfd06d16b4b155c3fabcfe51@plan9.bell-labs.com> 
Date: Sun,  6 Aug 2006 11:06:56 -0400
Message-Id: <20060806150717.6A4E3EAFD@mail.cse.psu.edu>
Topicbox-Message-UUID: 97ef41c6-ead1-11e9-9d60-3106f5b1d025


I hate to be the slowest guy in the room, but it's not clear where
this leaves me. If I understand the paragraph below, the upshot is
that there may be some unwritten blocks that copyworm thinks it has
to copy, but it's not the case that it is just trying to copy all
80G worth, written or not, onto my 50G disk. So, I either really do
have over 50G of blocks that it's trying to copy, or there is some
other problem. I see that the limit() value Geoff asked for is
basically devsize() for my source disk. Does that mean it's just too
much stuff?

Thanks for all the help.

Greg

> 
> 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.
>