On Tue, Jul 13, 2004 at 10:04:53PM +0200, Juergen Hannken-Illjes wrote:
> On Sun, Jul 11, 2004 at 07:00:18PM -0700, Chuck Silvers wrote:
> > On Mon, Jul 12, 2004 at 05:35:52AM +0900, YAMAMOTO Takashi wrote:
> > > besides, i can't believe that lwp is a right place to put
> > > a filesystem specific flag.
> > 
> > I agree with this entirely.  this feature ought not require hacks like this.
> > 
> > it seems to me that if the copy-on-write is going to use the same pool
> > of buffers that the original fs is using, then the the COW ought to be
> > resolved before modifying any data that the original fs is using.
> > that would also avoid the recursion, but much more cleanly.
> 
> It is not that simple. When a COW is resolved it has to allocate a block
> to save the unmodified block. This VOP_BALLOC() is the problem we are
> talking about. It has to read the indirect blocks and allocate a free block
> which may involve more lookups in cylinder groups etc.
> If any of these reads (through bread()) needs a buffer AND getnewbuf() tries
> to get a buffer by cleaning one from the queues this one may call the COW
> again (and again ...).

if we always resolved the COW before modifying a buffer, what you describe
could not occur, because any dirty buffer in the cache that getnewbuf()
might try to recycle would already have been copied earlier.  this does
require that any blocks that need to be modified in the process of
allocating blocks are pre-copied, but it looks like ffs_snapshot()
takes care of that.

-Chuck