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 <[EMAIL PROTECTED]> 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
>
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
