ggatec & ggated question/issue

[Brian McCann]

     That's exactly what's happening.  I put ggatec and ggated into
verbose mode, and tried the same thing.  When I cat the file, there
appears to be nothing going on in the logs for either ggatec or ggated
(or even when I do an ls for that matter).  This is definitely
different then what I expected, as I thought ggated just exported a
raw block device, ggatec creates the "other end" of the mount and a
dev node to point to the "tunnel", and mount then would just go
accross the tunnel.  Thinking the mount was RO and mounted async I
thought would get rid of any buffering at the client side.
     Yes, this is cool none the less, and a huge advancement, but
there's got to be a way to have it not buffer and actively read from
the virtual-block device on the client to the server.  Maybe I just
missed something in the man page...guess I'll try reading it again.

Thanks!
--Brian


On Fri, 14 Jan 2005 16:21:59 +0100, Holger Kipp <hk at alogis.com> wrote:
> On Fri, Jan 14, 2005 at 10:01:10AM -0500, Brian McCann wrote:
> > #echo "foo" > /share/bar
> >
> > Then mounting the client, I see the file.  Now I delete the file on
> > the server, I can still cat the file on the client.  It's like the
> > client can still read the old superblock or something.  Any ideas on
> > why this is doing this, or how to make it work so the client sees what
> > the server sees?
> 
> Looking at http://kerneltrap.org/node/3104 should explain this. My
> current idea (IANAKH) would be that the client is caching the directory
> and file data and is not notified that anything has changed on disk, so
> there is no reason to refresh the cached data from disk.
> 
> The behaviour sounds similar to two FreeBSD-Systems accessing the same disk
> device via SCSI (without synchronizing disk access).
> 
> Regards,
> Holger Kipp
>