[ENBD] Re: Doubled requests

[P.T. Breuer]

In article <Pine.HPX.4.43.0401161321310.22347-100000 at electra.kip.uni-heidelberg.de> you wrote:
> On Fri, 16 Jan 2004, Peter T. Breuer wrote:

> > I mean look at current->pid.

> I did. Seems to be the same process with pid 12903, sometimes kupdated
> (pid 6) is also doing some work in between:

Kupdated???? !!!!! That reminds me ...

> Jan 16 13:00:53 e004 kernel: cr: Suspicious block number: 126032 (last
> 126032) c83f2720 (c83f2720) pid: 12903 (12903)
> Jan 16 13:02:40 e004 kernel: cr: Suspicious block number: 9645 (last 9645)
> dc815e00 (dc815e00) pid: 12903 (6)

I would generally expect the writing process never to be "present" when
writes are actually delivered, because writes are asynchronous!

Writes go to the VMS system, and are flushed at irregular intervals.
The buffers should "age" and be flushed by a kernel thread, maybe
kupdated. But other events than kupdated running probably flush them
too, opportunistically.

I imagine that if the process 12903 is the context for the write at
the make_request level, when a flushed buffer is delivered to the
device, then it is simply an accidental consequence of it being
running at the time, and the opportunity has been "stolen" to get it to
do some little extra work on its way in and out of the kernel. So
it is just there because it is doing i/o.

You can test that theory by running some other i/o intensive process in
the background. Maybe one doing some writing to a huge file so that
it is the one pressuring the VMS to flush buffers first.

Since writes are always delivered asynchronously, I would also expect
doubles almost never to occur becuase they would go to the VMS instead
of the device first, and the second write would hit the VMS buffer
established to hold the first.

You must somehow have two writes sent either side of a flush event.
This is rare. You should be able to influence the frequency by
increasing the frequency of flushing, i.e., by decreasing the max
allowed buffer age in /proc/.....bdflush/*, or by decreasing the
amnount of ram available, or by running a background process that fills
memory quickly and leads to a flush.

But there is no need to check - I am pretty sure.

What you should try and do is use DIRECT i/o, or raw i/o, to avoid
the VMS. If the effect persists, it is not due to the VMS.

Peter