Re: Cache flush question.

[Rob Landley <rlandley@parallels.com>]

On 01/05/2011 05:15 PM, Daniel Stodden wrote:
> On Tue, 2011-01-04 at 09:32 -0500, Trond Myklebust wrote:
>> On Tue, 2011-01-04 at 00:44 -0800, Daniel Stodden wrote:
>>> Hi anyone.
>>>
>>> If somebody's got a sec to enlighten me, there's some phenomenon I
>>> recently came across and found somewhat counterintuitive first.
>>>
>>> Whenever I
>>>
>>>   1. Dirty a bunch of pages backed by an NFS mount on some server.
>>>
>>>   2. Block the traffic with iptables (TCP, assuming that mattered).
>>>      Still plenty of writeback pending.
>>>
>>>   3. Sync
>>>
>>> I see #3 drive the dirty count in /proc/meminfo drop back to
>>> almost-zero, immediately. The sync itself blocks, though.
>>>
>>> So the pages are called clean the moment the write got queued, not
>>> acked? Leaving the rest just to retransmits by the socket then? Is this
>>> just done so because one can, or would that order rather matter for
>>> consistency?
>>
>> Take a look at the 'Writeback:' count, which should turn non-zero when
>> you hit #3.
>>
>> The VM allows pages to be either dirty or in writeback, but not both at
>> the same time. This is not NFS-specific. The same rule applies to local
>> filesystems.
>
> Ah. That explains everything. Actually a question then, thanks for the
> clarification :)
>
> Rob Landley's comment regarding tx queue size somewhat made a good point
> too.

Not nearly as good as I thought at the time.

 > But, given the rates I see, this queues mostly cache pages on the
> transport, not copies, right?

Easy enough to tell: there's a "Writeback" field in /proc/meminfo.  Add 
'em up and see what's missing.

Rob