Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: The INN/mmap bug | Date | Tue, 19 Sep 2000 01:16:47 +0200 |
| |
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/
|  |