m_theologos wrote:

>>If shadow propogation were delegated to a separate thread rather than
>>performed inline, the overhead would disappear provided the network
>>bandwidth was up to the effect disk write bandwidth.
>>
>>
>>
>
>Is easy for you to do it?
>
>

Easy? No, I doubt think it is easy. There needs to be a communication
mechanism between the working thread and the shadow thread that
preserves page write order, and a lock must be held on the buffer to
prevent page changes until the page has been sent to all shadows. On
the other hand, there is only one class involved, PageCache. I'd call
it a two or three day project for anyone who understands the subtleties
of PageCache.

Practically speaking, however, I'm not the one to do it.

>I proposed the shadow sollution because is easy to implement (AFAIK).
>Of course, better, IMHO is to have on the main server let's say S1 a
>client for the shadow server S2 and to send to him only the commands
>which changes the data (ie. not SELECTs) and let the fbserver from S2
>to manage the shadow db. (in fact a middleware on the server side).
>
>What do you think?
>
>

I think this is undoable for shadows.

>
>
>P.S.: Why do you say that the replication is more efficient on net
>b/width? On the shadow file the server doesn't propagate (apply) the
>changes only?
>
>

A single insert is a single message for replication, but may require
writing a number of data pages (many if garbage collection is involved),
a pointer page, a number of index pages, maybe a couple of index bucket
splits, the page management page, etc. So an insert that may require
only a 100 bytes of in the replication log could, for a 4K data page,
result in 40K bytes of miscellaneous page writes over 10 NFS/RPC round
trips.



--

Jim Starkey
Netfrastructure, Inc.
978 526-1376