Date: Mon, 5 Oct 1998 23:06:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: freebsd-fs@FreeBSD.ORG Cc: tlambert@primenet.com, oppermann@pipeline.ch Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <199810052306.QAA28852@usr04.primenet.com> In-Reply-To: <5889.907614151@gjp.erols.com> from "Gary Palmer" at Oct 5, 98 03:02:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > 75% reads > > > > > > 15% writes > > > > > > 8% directory search operations > > > > > > 2% other > > > This would be a very good idea. > > > > It would be best to instrument at the lowest level, *below* where > > soft updates does its implicit write gathering, and/or any elevator > > sorting occurs. > > Depends on what you want to gather. The stats quotes above would seem to be > (IMHO) application<->FS layer transactions, not FS<->disk transactions. The FS is externalized via NCP, directly. The Novell stats are FS abstraction (NCP) to disk. You could argue that a network adapter was not a baseband connected disk controller, but Novell would disagree. The thing I would want instrumented, personally, is controller-to-disk transactions, with the intent of minimizing the number of transactions which occur. If the intent is to say that the disk is the bottleneck, then finding out how to minimize references to the bottleneck seems to be the way to go. This assumes that the disk is the bottleneck (which is why I suggested instrumenting the tagged command queueing to gather fill statistics on the tag queue. > And to be honest, you'd need both sets of figures (as well as a good > bit of analysis code which goes far beyond percentages) to obtain any > sort of `optimizations' based off those figures. Right. You'd need non-statistical profiling, probably using the instruction counter, and instrument on function entry and exit, as well as cycle elimination for elapsed time. While at Artisoft, we actually build a profiling system based on a Microsoft compiler flag for function entry instrumentation, coupled with stack hacks for function exit instrumentation (the compiler could only instrument entry) to gather this information. It was incidently on the Berkeley FFS in the Heidemann framework ported to Windows 95, ...including Soft Updates, implemented by Matt Day. We learned quite a few interesting things about the Windows 95 VM system, and VFAT page management. 8-(. > It would be really interesting to instrument at the application<->FS > layer a few of the different server types (POP3/MTA only, IMAP/MTA > only, news, etc) and see just what the access patterns are. I'm > personally very curious about the POP3/MTA systems using off-the-shelf > software. Actually, this is pretty trivial, using procfs and a wrapper script to initiate profiling. Sean has laid quite a bit of groundwork in this area (he recently got "truss" running on the Alpha, in fact). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199810052306.QAA28852>