Slave share (or SMB caching proxy) suggestion

[Aleksander Budzynowski]

Hi all,

Forgive me if something like this has been suggested before or already
implemented, or was deemed unfeasible for some reason. I briefly ran my
idea past Tridgell at LCA last month but I don't think I explained it very
well.
The idea is to have a share in one location that works essentially as a
real-time replica of another share, which is located say across the WAN.

The approach, to me, seems simple: the "slave" server pretends to be just
another ordinary client of the "master", and requests locks and oplocks as
appropriate, to ensure that concurrent access is fairly safe. Since the
server needs no modification (could be a Windows box), and we
already have SMB client code, I believe this would be fairly simple to
implement.

I'm not sure if it would provide acceptable performance in general, but I'm
sure there are *some* applications where this would work very well, or at
least be better than the, um, alternatives.

While the details could vary, this is the picture in my mind:

The slave server stores a local copy of the entire share, checking if files
are up-to-date each time they are accessed. So it could double as a simple
off-site backup, and could be accessed even if the link to the master is
down. You might have a script or some such which ensures that everything is
up-to-date weekly.

My understanding of SMB is not extensive, but here's how I imagine a typical
request will flow:

-Local client wants to get a file (and oplock it)
-Slave gets an oplock for the file from the master
-Slave checks if local copy has same date as master copy (if not, local copy
is updated)
-File is sent to client
-If client modifies file, slave can cache changes locally, or immediately
send them on to master
-If master breaks oplock with slave, slave breaks oplock with client

So. Does this idea have merit? Has it already been done? Is there some fatal
flaw?


Cheers,

Aleksander Budzynowski