Date: Thu, 24 Sep 1998 20:16:24 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: "Robert V. Baron" <rvb@cs.cmu.edu> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, committers@FreeBSD.ORG Subject: Re: Having some serious file write / mmap inconsistancy problems Message-ID: <199809250316.UAA22825@apollo.backplane.com> References: <199809241837.OAA26496@lor.watermarkgroup.com> <yzsu31x7wn8.fsf@sicily.odyssey.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:I have a possibly similar possibly different problem that could be
:explained (I think) with this sort of an inconsistency. I have a file
:system (Coda). Its vnodes contain Coda state but also contain the
:...
:same. But cmp different (cmp uses mmap). ALso you can not execute
:the file because the data is garbled (maping again). Again diff works
:fine. Ok so somehow I've managed to separate the object from the
:...
:the copies cmp and execute fine. What I don't totally understand at
:NOTE:
:There is an added complexity here, because we're probably mapping the
:object associated with the Coda vnode (not the ufs vnode). So having
:two objects involved might be my problem. But I really can not
:understand why it would be intermittent.
I think this is a different problem. The bug I found didn't have
an inconsistancy problem between mmap() and read(). When the data
got corrupted it got corrupted for both.
In Coda, are you changing the mappings in the bp's without invalidating
the pmaps relating to the underlying pages? I'm not familiar with Coda,
but if you are using some sort of backing store and 'mixing' backed pages
with unbacked changes, there's certainly the potential to forget something
that results in the pmaps being out of sync with a vnode mapping.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809250316.UAA22825>