External journal on flash drive

[Mika Liljeberg]

On Tue, 2004-09-14 at 01:02, Stephen C. Tweedie wrote:
> >  or are there blocks that are particularly "hot"?
> 
> There is one: the journal superblock.  It's not updated _hugely_ often,
> but it is updated whenever we "checkpoint" the journal (ie. when we
> remove old transactions from the tail end of the journal.)  I haven't
> measured it but I'd expect we're updating that maybe 2 or 3 times more
> rapidly than other journal blocks.

That's less than ideal but not too bad. Presumably a large journal will
help here?

> > 2) Currently, the main drive seems to spin up within 60 seconds after a
> > write access. I would like the checkpointing to occur only when the
> > journal device is getting full. How can I tune this?
> 
> That's not related to journal activity --- that's normal writeback.
> 
> The way the journal works is that it makes sure we update transactions
> atomically, in the journal, before they are allowed to undergo normal
> writeback.

Ah, I see. Does this also hold for data_journal mode?

> However, once the transaction _has_ committed, the journal is almost
> entirely out of the picture.  The only interest the journal retains in
> the updated metadata is that we have to make sure that we don't reuse
> the journal record for that transaction until all of the metadata has
> undergone its normal writeback (otherwise we'd risk having no record of
> it after a crash!)  Other than that, it's up to the normal VM writeback
> to write the updated metadata to its home location on disk at that
> point. 

Sounds like my best bet would be to have my filesystems in data_journal
mode and to configure the bdflush parameters to delay writeback as much
as possible. If I understand correctly, that should allow for maximal
spin down times and still maintain full data integrity after a crash.
For ext3 filesystems, anyway. :-|

Thanks for the explanation,

	MikaL