Andreas Dilger wrote:
>
> Daniel writes:
> > Alexander Viro wrote:
> > > On Mon, 18 Sep 2000, Andreas Dilger wrote:
> > > > This may actually be a problem in the future... what about shared access
> > > > block devices like FCAL or a distributed filesystem? It has to be
> > > > possible for pages to become non-uptodate in a sane way.
> > >
> > > So what the heck do you do when something modifies mmaped page when you
> > > get the change of on-disk one? Say it, writer is notified that write had
> > > been completed, sends packet to you and you flip a bit on a page that
> > > happens to be mmaped on the place where write had happened.
> > >
> > > Write-through-pagecache is OK, but write straight to disk bypassing the
> > > cache? Welcome to the fun with aliases...
> >
> > Yes, I think that's one rule we can write down right now: to update a
> > block on disk you have to go through the buffer. Not going through
> > the buffer is about the same as accessing a semaphore-protected
> > resource without bothering with the semaphore.
>
> What I'm getting at is that the local system didn't make the change at all,
> so there is _no way_ to make the write go through the local cache.
> The write to disk happens on a remote system. The only thing that happens
> on the local system is that it gets a message that a buffer is invalid.
>
> You don't want to have to re-send each buffer to each system that ever
> read it. It is much better to simply invalidate the cache, and only if
> the client accesses it again will it be re-read.
>
> It should be possible to mark a page non-uptodate, so that the next time
> it is accessed locally it will re-read the _new_ data from disk. Think
> of the fs "revalidate" method.
Yes, this is a cache coherency protocol. I should have said you have
to go through the *buffer head*, it's what I meant. You can't just
invalidate the buffer any time you want, you have to wait until there
are no readers/writers first. Ooh, my head hurts, I was just trying
to write a simple filesystem extension and now I'm getting sucked into
distributed filesystems...
*** goes back to hunting down tailmerge races
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:19 EST