On Tue, Jun 25, 2002 at 10:03:47AM -0700, Andrew Morton wrote:
> If it's because of the disk-spins-up-too-much problem then
> that can be addressed by allowing the commit interval to be
> set to larger values.
The updated commit interval will only affect new transactions, correct?
In other words, when changing the commit interval from t_old to t_new,
it will take t_old seconds until we can be certain there are only
transactions with a t_new expiry interval in the queue? Or is there a
way to flush the current queue of transactions, eg. by fsync()ing the
underlying block device, or by sending a magic signal to kjournald? If
such manual interaction is possible, it'd also be handy to have the
opposite: a be-anal mode (eg. if commit interval==0) meaning 'do not
write any transaction to disk until explicitly told to'. This parallels
the way kupdated can be tuned for traditional write-back.
Regards,
Daniel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:13 EST