Date: Wed, 2 Apr 1997 10:53:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pmchen@eecs.umich.edu (Peter M. Chen) Cc: freebsd-hackers@freebsd.org Subject: Re: question on buffer cache and VMIO Message-ID: <199704021753.KAA13869@phaeton.artisoft.com> In-Reply-To: <199704020315.WAA03318@life.eecs.umich.edu> from "Peter M. Chen" at Apr 1, 97 10:15:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >One big issue: I'm not sure how this will interact with the "soft > >updates" facility described in the Ganger/Patt paper. This facility > >is a planned future feature on nearly everyone's whiteboards. If you > >have read the paper, I can discuss the idea of a generic implementation > >that is not FS dependent (like the paper's Appendix A UFS example is) > >and the ramifications that would have on FS/cache interaction. > > Soft updates allow you to delay metadata disk writes (just like data disk > writes) without losing file system integrity. However, you will lose more > metadata in a crash than before. E.g. if you mkdir then crash a few seconds > later, soft updates will lose that directory (but in a way that doesn't > compromise file system integrity). This is the same tradeoff that's made > with data. Think of it as allowing more "data loss" without "integrity loss". I was actually thinking more in terms of where the soft updates must be implements so as to not fall back to DOW (Delayed Ordered Write) performance in the unified cache case. Effectively, they must be implemented at the VFS/BIO boundry layer (I've made a couple other postings on this on the -current list, if you are interested). I actually believe the FS-level soft updates implementation that is currently being worked on by a former CSRG member will have at most a 160% of current speed (the same as a DOW implementation in FreeBSD). The effect on BSDI and other non-cache unified BSD's should be significantly higher -- but will be offset by the fact that cache unification is a significant win (it saves a bmap per copyin/out, for one thing). The problem is that soft updates implemented in an FS that does not do physical block I/O as a result of a BIO request (instead, writing a page, marking it dirty, etc.) is somewhat antithetical to the involvement of the BIO subsystem in the node dependency scheduling. The Ganger/Patt paper Appendix A is a non-generic implementation of soft updates, and statically orders operations on an assumption of how a BIO will traditionally behave. The dependency graph is "closed" to the implementation. Effectively, this makes the graph edge-opaque. We can do a graph reduction on the edge-opaque graph, and what we get out will look remarkably like the graph we would get if we were to intentionally implement DOW instead of soft updates. Unfortunately, the Ganger/Patt paper did not take a graph theory approach to modelling the FS event/handler/order-dependency for SVR4 UFS, so it's not easily relocated without another analysis of the FS (on the plus side, a system based on such a model can be used on any FS type, if the model is seperated from the implementation of the Soft Updates itself). All this leads to the question "How intrusive is Rio at the BIO level, and what are the actual interface impacts that will result?". Effectively, those of us without battery-backed RAM, or RAM that is somehow not persistant over a crash/boot cycle, will need to be able to "switch Rio off", and we'll still want to get the benefit of soft updates when we do. Ideally, we would want a well-defined bottom end interface for VFS's that need to read and write at the block level, and the Rio code, the Soft Update code, and the system-supplied BIO would all use the same interface (the BIO only on the top end, the VFS only on the bottom end, and Rio and SU on both the top and bottom, so they can be stacked). Since this probably isn't going to happen in the near future without some architectural control concessions by FreeBSD, the next best thing to do is to understand the impact that integrating both will have on each other. Regards, 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?199704021753.KAA13869>