In the spirit of sharing actual numbers and details for things that I lefta bit unclear in an earlier entry , here is more:

First, we switched to the deadline IO scheduler (from the default cfq ). I did brief tests with the noop scheduler and found itbasically no different from deadline for my test setup, and deadline may have some advantages for us with more realistic IO loads.

My IO tests were sequential read and write IO, performed directlyon a test fileserver , which usesa single iSCSI backend

Since this appears necessary , here is how todeprecate some bit of your program in a way that makes sysadmins hateyou as little as possible.

• first, add a warning to your documentation and a 'compatibilityswitch' that causes your program to use the old behavior that youare deprecating. Of course, the compatibility switch currently doesnothing since the old behavior is the current behavior, but nowyou've let people start explicitly specifying that they need theold behavior.

  If you are changing the behavior of your program

Aristotle Pagaltzis 's comment on my previous entry prodded me into doing somemore thinking about this, and his entry on RFC 2119 usage has persuaded me that thereare actually four degrees of requirements that it's useful toput into specifications.

Put simply, I'd say that they are:

• allowed: you can do this, and some people will (so be prepared to copewith it).
• recommended: we think that you should do this.
• should: not doing this causes problems for

Something I've been mulling over lately is the the effects of A rulefor Internet software on specifications and how strongyou make requirements in them.

To put it one way: a 'MUST' in a specification makes a handy club tobeat people with, but perhaps they are best reserved for things thatare absolutely required in order to make the protocol work, becausein practice that is what is going to happen anyways.

(Note that a MUST often does not make an effective club, because ifit doesn