Re: laptops and journalling filesystems

[Andrew Morton]

Rik van Riel wrote:
> 
> On Tue, 31 Jul 2001, Andrew Morton wrote:
> > Tony Lill wrote:
> > >
> > > Do any of the current batch of journalling filesystems NOT diddle the
> > > disk every 5 seconds?
> 
> > Unfortunately ext3 defeats the trick of setting the kupdate
> > interval to something huge.  On my list of things-to-do.
> >
> > Probably it's as simple as setting the commit timer to
> > a large interval (grep for "HZ" in fs/jbd/journal.c).
> 
> How about using bdf_prm.b_un.interval as the commit
> timer for ext3 ?

It may be best to keep them separate - they do rather different
things, and the system may have multiple filesystems.  Plus
it'd be yet another thing we need which isn't exported :(

What would be nice would be the ability for external code to be
notified of kupdate and bdflush activity - that way we can
do what you suggest for laptops - do all the disk activity in
a single hit.

The ability to know when bdflush is woken would be useful
for other VM-related reasons.  Generally the bulk of ext3 data
is writable by bdflush and freeable by the releasepage()
address_space op (aka try_to_free_buffers).  But metadata
doesn't have an address_space, which is why we can get a 
bit gummed up at times.   The best fix for this is to take
over all the IO scheduling and drop the ext3 structures from the
buffers at IO completion time.  That's version 2.

> With the addition that normal writeouts to disk (those
> go via the ext3 code, right?) also trigger a commit, if
> the last commit was long enough ago to not impact system
> efficiency.
> 
> This way you should, on laptops, have the ext3 commit
> happening either at the same time as the kflushd write
> (triggered by the write) or the next kflushd interval
> away.

When ext3 commits, all data is written to its final resting place
on disk, and then all metadata is written to the journal and then
released for normal writeback.  So if we were to start IO on that
writeback data immediately, there is no need for kupdate at all.
That would work, as a special laptop feature.  A mount option or
tune2fs setting.    Any synchronous operation would force an immediate
commit, of course.

-