Date: Fri, 14 Jan 2005 11:28:47 -0500 From: Brian McCann <bjmccann@gmail.com> To: Holger Kipp <hk@alogis.com> Cc: freebsd-stable@freebsd.org Subject: Re: ggatec & ggated question/issue Message-ID: <2b5f066d05011408282ec9c908@mail.gmail.com> In-Reply-To: <20050114152159.GA10608@intserv.int1.b.intern> References: <2b5f066d050114070172ac895f@mail.gmail.com> <20050114152159.GA10608@intserv.int1.b.intern>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b5f066d05011408282ec9c908>