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 _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
