Date: Fri, 31 May 1996 14:49:30 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: rashid@rk.ios.com, terry@lambert.org, davidg@Root.COM, hackers@freebsd.org, jgreco@solaria.sol.net Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199605312149.OAA18849@phaeton.artisoft.com> In-Reply-To: <199605301011.UAA14948@godzilla.zeta.org.au> from "Bruce Evans" at May 30, 96 08:11:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >There is a school of thought that says "shall be updated" in POSIX is > >not the same as "shall be committed to stable storage" (the traditional > >BSD implementation). > > When was this traditional? It's just historical behaviour; has to do (in 4.3) with whether or not O_ASYNC is set or not. The write is done, regardless; it *will* be happening, not as a result of LRU. The only remaining question is "how soon", which bears on how much gathering will effectively take place on multiple references. The bigger the FS, the sparser the outcome. > >This would let access times be updated in core, but only scheduled to > >be written at a later time (not forced out immediately). > > 4.4BSD and I think Net/2 always only scheduled them to be written at a > later time. At the end of every read (incorrectly including unsuccessful > ones), access times are marked for update: > > ip->i_flag |= IN_ACCESS; /* see ufs_readwrite.c */ > > At certain checkpoints, the access times are updated. E.g., in ufs_close() > > if (inuse && !locked) > ITIMES(ip, &time, &time); > > If IN_ACCESS is set, this sets the access time in-core, sets IN_MODIFIED, and > clears IN_ACCESS. It doesn't write the inode. Setting IN_MODIFIED schedules > the inode to be written on the next sync, or when it is reused. ffs_sync() > calls VOP_UPDATE() with the sync-update flag clear and ffs_update() schedules > a delayed write. The thing should be updated when it is LRU'ed out of cache, not when it is synced. But since the cache is vnode data-block based in its use of LRU's, this can't happen. All non-data-block FS data gets committed an average of 30 seconds after it is changed (the sync interval). metadata of any kind is a second class citizen in vnode/offset based block cacheing. 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?199605312149.OAA18849>