Re: Making statCounter.syscalls.disk counters more consistent

On Thu, 18 Jul 2003, Robert Collins wrote:

> This won't increment the counters: the statCounter used by cachemanager
> is not the statCounter available to the external unlinkd process.

yeah, my mistake, it belongs in the other part.

> None of the above are safe. They are all potentially racey on SMP
> machines. You need to use interlocked increments to safe perform such
> counts.

Okay. There is already a call to increment disk.unlinks in aiops.c, so
if it is unsafe I guess it should be removed.

> However, aufs -does- record the syscall counts: during the
> scheduling operation, not during the worker threads actual call. That is
> thread safe today..

You mean as reported in the squidaio_counts cachemgr page?

I'm trying to make the '5min' etc counts more consistent among all
storage schemes. In my tests with AUFS, they are all zero, except
for writes (which must be going through file_write() I guess?):

        syscalls.polls = 122.796291/sec
        syscalls.disk.opens = 0.000000/sec
        syscalls.disk.closes = 0.000000/sec
        syscalls.disk.reads = 0.000000/sec
        syscalls.disk.writes = 180.793150/sec
        syscalls.disk.seeks = 0.000000/sec
        syscalls.disk.unlinks = 0.000000/sec

So I should either increment the counters somewhere else, or
not at all and say that its too hard for AUFS.

> > - statCounter.syscalls.disk.reads++;
> > if (FD_READ_METHOD(fd, hdr_buf, SM_PAGE_SIZE) < 0) {
> > debug(47, 1) ("storeAufsDirRebuildFromDirectory: read(FD %d): %s\n",
> > fd, xstrerror());
>
> Why are you removing this one? (Is it double counted?)

Looks like I didn't give it enough thought/testing. It might
be double counted, but I'm not sure. I can leave it.
Received on Thu Jul 17 2003 - 18:13:47 MDT