> > > 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?
>
> Yes, unless:
> > 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?
>
> an fsync() on any file or directory on the filesystem will ensure that
> all old transactions have completed, and a sync() will ensure that any
> old transactions are at least on their way to disk.
Ugh, does that mean that if I
"sync ; poweroff"
my data are not safe?
Pavel
-- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa - 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/