put in another way: if a block is not idle, the modifier creates a small
'context of modification', which context is the scheduled properly,
acording to filesystem metadata dependencies. The modifier itself does not
get blocked in any way, normally.
as a gedankenexperiment, if we stop the disk and do all kinds of crazy
modifications to the filesystem, the number of such contexts will
increase, but it will be bound by a certain limit, because later contexts
are merged with former contexts. (it cannot grow unlimited, which would be
a nasty denial of service attack)
if system resources do not allow to have this 'natural upper limit' number
of modification contexts, it has to be limited 'artificially', by blocking
on a get_modification_context() call. For the normal case this does not
block.
-- mingo