Date: Tue, 14 Nov 1995 01:08:06 -0800 From: David Greenman <davidg@Root.COM> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: current@freebsd.org Message-ID: <199511140908.BAA00238@corbin.Root.COM> In-Reply-To: Your message of "Tue, 14 Nov 95 09:51:26 %2B0100." <336.816339086@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> > update_every_3_sec()
>> > {
>> > static int i;
>> >
>> > for all buffers {
>> > if ((blockno % 10) == i)
>> > write it
>> > }
>> > i = ++i % 10;
>> > }
>> >
>> >give more io traffic ?
>>
>> Because delayed write buffers are delayed for a reason. It's the
>> expectation that additional data/changes will be made to the buffer before
>> it is written out. In the case where stuff is being appended to files via
>> small writes (like log files, for instance), doing an update 10 times more
>> often may very well increase the number of writes by 10 times.
>
>I still don't follow you.
>
>Are we talking about the same thing ?
Perhaps not.
>The mean time between updates for any one particular buffer is still
>30 seconds, so how can this change so much ? We just stage the
>writes instead of doing them all at the same time.
>
>Unless you can show me where we prefer buffers with a particular last
>decimal digit in their block-numbers then I have a hard time beliving
>your results...
Umm, this isn't desired - you'll lose the ability to do write clustering.
The scheme I implemented did buffer aging.
>I had a patch (crude hack really) for this back in Pleasant Hill but I have
>no idea where to find it now, but it didn't show any adverse effects for me,
>quite the contrary... It cured the hangs I had, which was the kind
>which would be signalled by a significant rattle from the disks...
What can I say. I tried it and it increased the disk I/O and worse,
introduced some unpleasant side-effects. My analysis of the increased disk
I/O showed that most (all?) of it was caused by additional inode updates.
For delayed writes the inodes are normally updated only after all of the
blocks have been written out - in other words, after the sync. A general
analysis of the disk I/O that occurs during a sync showed that most of it
was due to updating access times on files. Doing the slow dribble increased
the frequency of the access time updates. I tried various different
approaches - including aging things at different rates, etc, but finally
gave up in disgust and threw out the code.
-DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511140908.BAA00238>