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.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
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