Date: Thu, 16 Nov 1995 01:11:31 +1100 From: Bruce Evans <bde@zeta.org.au> To: davidg@Root.COM, phk@critter.tfs.com Cc: current@freebsd.org Subject: disksort Message-ID: <199511151411.BAA06956@godzilla.zeta.org.au>
next 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.
And because the above strategy is sort of like unclustering by a factor
of 10, or an interleave of 10. It guarantees that the efficiency is
most 1/10 of the maximum possible efficiency.
>> >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 think clustering at the file system level would still work.
I think the basic scheme should be:
1) almost never write a buffer that hasn't been dirty for a long time
(30 seconds or so).
2) write 1/N of the data to be written (not necessarily 1/N of the
dirty buffers) every full_update_period/N seconds. Normally seek
across about 1/N of the disk each time.
3) somehow stop synchronous updates from interfering with (1).
4) somehow stop reads/readahead from intefering with the seeks in (2).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511151411.BAA06956>