Theodore Tso wrote: > > On Fri, Feb 08, 2002 at 12:59:50PM -0800, Andrew Morton wrote: > > The other (complimentary) option is to simply hack mke2fs so that it permits > > larger journals. In e2fsprogs's misc/util.c:figure_journal_size(): > > Note though that interactivity may suffer with larger journals; when > it finally *does* come time to flush the journal, the system may > become very non-responsive until the journal is actually completely > flushed. Yes. Once we get into forcing checkpoints, new writers can get *seriously* gummed up, because the filesystem is actively writing things to the main disk (ie: very seek-intensive), which is much slower than journal writes. And increasing the journal size will increase the amount of data which is checkpointed, when a checkpoint force happens. Neil Brown found that his NFS server was getting bitten by this - pauses of a few seconds every thirty seconds, I think. His workaround was to drastically shorten the kupdate interval so that kupdate performs the nice smooth checkpointing for us. This is discussed in Daniel Robbins' second article, at http://www-106.ibm.com/developerworks/linux/library/l-fs8/ ext3's checkpointing code is too drastic at present - too much, too late, too infrequent. We do need a native solution, rather than borrowing kupdate functionality, I guess. -
