Date: Sun, 2 Apr 2000 21:53:24 +0800 From: Adrian Chadd <adrian@freebsd.org> To: vova@express.ru Cc: Bernd Walter <ticso@cicely.de>, freebsd-fs@FreeBSD.ORG Subject: Re: SCSI bus Message-ID: <20000402215318.E21291@ewok.creative.net.au> In-Reply-To: <Pine.BSF.4.21.0004021534050.24770-100000@lanturn.kmost.express.ru>; from vova@express.ru on Sun, Apr 02, 2000 at 03:38:10PM %2B0400 References: <20000402110216.A24876@cicely8.cicely.de> <Pine.BSF.4.21.0004021534050.24770-100000@lanturn.kmost.express.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 02, 2000, vova@express.ru wrote: > On Sun, 2 Apr 2000, Bernd Walter wrote: > > > > > I don't expect this to work because the readonly side can't know when the > > > > incore informations outdates. > > > > > > Yes, it can be a problem, but may be this may be solved by disabling any > > > cache on read-only side (or setting expire time in one sec) ? > > > > You can't diable readcaching completely. > > Say you need the inode, then you will read it and finaly use it. > > You don't reread it for every single byte you access which creates some kind of > > read cache. And there are much more complex points like this sample. > > Ok, have kernel algorithm to "expire" cached vnodes ? Or vnodes only > pushed out by new pages ? > > In my case writes - relative rare case then reads and I can wait for some > timeout while my in-kernel vnodes will dropped to see new from disk Think from a metadata point of view - if you're half way through updating a directory on a write, and you try reading that directory, you are going to get very weird results. You'd need to have a filesystem that supports this kind of access at the very outside. FFS wasn't designed for this. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000402215318.E21291>