The per-NFS-operation data for NFS mounts in /proc/self/mountstats

The last big chunk of statistics in mountstats is a bunch of separate information for each NFS operation. Since theexact operations are version-specific, the list of operations dependson the NFS version in use; however, the statistics are the same forall protocols (and all operations).

A typical example (for NFS v3) looks like this:

per-op statistics        NULL: 0 0 0 0 0 0 0 0     GETATTR: 192686 192688 0 22

What reloading a Python module really does

If you're like me, your initial naive idea of what reload() does isthat it re-imports the module and then replaces the old module objectin sys.modules with the new module object. Except that that can't beright, because that would leave references to the old module object inany other module that had imported the module. So the better but stillincorrect vision of reloading is that it re-imports the module as a newmodule object then overwrites the old module's


The xprt: data for NFS mounts in /proc/self/mountstats

The xprt: line in mountstats reports variousbits of overall NFS RPC information for the particular NFS mount inquestion. The information reported differs somewhat depending on theprotocol in question, so I'm going to start by discussing the TCPstats. These look like (for the 1.0 format):

xprt:   tcp 695 1 1 0 16 96099368 96091328 6383 3419332134

The bytes and events data for NFS mounts in /proc/self/mountstats

The per NFS mount mountstats performance stats ( see here foran introduction ) have two sets of high levelstatistics, reported in the bytes: and events: lines. Both ofthese come from counters that are described in comments in include/linux/nfs_iostat.h in the kernel source.Of the two, the simpler is bytes: .

A typical bytes: line looks like:

bytes:  2320629391 2297630544 0 0

What is in /proc/self/mountstats for NFS mounts: an introduction

As I discovered recently , for several yearsLinux kernels have made a huge amount of per-mount NFS performancestatistics visible in /proc/self/mountstat . Unfortunately none ofthis is documented. Because I have a use for the information and I'm aglutton for punishment, I'm going to write up what I've found out.Mountstats contains so much information that this is going to takeseveral entries.

To start with, let's talk about the overall format of a filesystementry.


What your User-Agent header should include and why

I wound up having a discussion about this in the context of a feedreader and it caused me to have a realization or two, so I've decided towrite up my views on this. All of this is mostly from the perspective ofa website operator; there are other ones.

There are three different cases: when you are writing a user agent,when you are writing a web robot, and when you are writing a web robotlibrary (which will be used by possibly many web robot operators)


Centralizing syslogs as an easy way to improve your environment

If your environment is on the low end of the organized 'DevOps'spectrum, here's an easy improvement that I urge you to make rightaway: create a central syslog server that all of your machines echotheir syslogs to. Disk space is cheap today and if you have an ordinarysized environment you don't need a particularly powerful machine or aparticularly fast disk system ( at least if you turn off synchronoussyslog writes on your log host ). Once you've set upthe syslog server all


Spammers illustrating, well, something

I'm on the general mailing list for Exim andover time I've become used to seeing what I'll call 'please do myhomework' requests there. By this I don't quite mean literally requestsfor this (so far no one seems to assign configuring Exim as homeworkfor some class), but instead requests for help with problems whichclearly show that the requester has not attempted to help themselves andis turning to the mailing list as a last resort; instead the mailinglist is serving


Universities and long term perspectives

I expect that in many places my habit of looking five or ten years intothe future for things I'm considering would be seen as more than alittle bit daft and pointless. In a company the problems you have infive or ten years are likely to look much different than what you havetoday; if a system has survived at all, it's quite likely to have grownor otherwise changed drastically as the business scaled up or mutated(this is especially true in startups and other small companies that are


Why I put configuration management systems over packaging systems

A debate has broken out in the comments on my previous entry over whether you should manage systemconfigurations through a configuration management system or throughthe system's package management. Although I once wrote a number of entries a fewyears ago in support of this view, I have now changed my mind and thinkthat configuration management software does a better job for bothpragmatic and high level reasons.

The pragmatics of the situation are clear: no packaging system today isreally set up for this and so you can't really