Date: Sat, 1 Jun 1996 16:08:39 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: dufault@hda, terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199606012308.QAA22341@phaeton.artisoft.com> In-Reply-To: <199606011243.WAA17058@godzilla.zeta.org.au> from "Bruce Evans" at Jun 1, 96 10:43:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Even with _POSIX_SYNCHRONOUS_IO and nothing opened *SYNC (that is, > >you can be as aggressive as you are clever), POSIX requires that > >the file access times be updated when a "stat" or "fstat" happens > >and when no process has the file open. This precludes a standard > >way of efficiently handling files that are being rapidly opened > >and closed where you don't care about the access times. I think > >they should have changed this part of the spec when they defined > >the sychronous I/O to let you only update the access fields when > >the associated I/O takes place, permitting standard "aggressively > >asynchronous" behavior. > > It already permits agressive async behaviour, because update has > nothing to do with writing to disk. It just requires the update > marks (if any) to be converted to actual timestamps. Bruce is right. "Marked for update" can mean "have a flag set so that the current time, when update is done, is inserted into the field in place of the time that was formerly in the field". "Shall be updated" can mean "the current time is inserted into the field in place of the time that was formerly in the field". In both cases, the page and/or block that contains the data that was modified is "marked dirty" following the actual update. What is at issue is whether once it is marked dirty, the write can or can not be delayed over a the update daemon attempting a sync, or whether the dirty block *must* be written. The issue is one of latency, persistance, and cache cleaning algorithms. The LRU which applies to cache cleaning algoritm for cache blocks for a referenced file is *different* than the cache cleaning algorithm applied to pages/block not hung off an in core vnode (for reasons which should be obvious and which are derivitive of the buffer/VM cache unification method which was employed. I personally believe that most of the POSIX update semantic overhead imposed by making the ordering guarantees UFS makes to guarantee deterministic recovers of FS data, can be traced to being caused by the update daemon not imposing LRU list restrictions on data other than buffers hung off of vnodes. There is more than one way to solve the overhead problem. One way would be to use LRU's to increase cache locality for metadata instead of just for data in the unified cache model. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606012308.QAA22341>