Do any of the current batch of journalling filesystems NOT diddle the
disk every 5 seconds? I've tried reiser and ext3 and they're both
antithetic to spinning down the disk. Any plans to fix this bug in
future kernels?
--
Tony Lill, [email protected]
President, A. J. Lill Consultants fax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
--------------- http://www.ajlc.waterloo.on.ca/ ----------------
"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
Tony Lill wrote:
>
> Do any of the current batch of journalling filesystems NOT diddle the
> disk every 5 seconds? I've tried reiser and ext3 and they're both
> antithetic to spinning down the disk. Any plans to fix this bug in
> future kernels?
If you mount everything with `noatime' there's nothing to
be written unless you're writing stuff.
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).
Commits are driven by either a timer expiry or by the
journal getting too full. If the interval is set large
then probably journal-full will be the main reason for
running a commit.
Of course, if the interval is set to 15 minutes and
you crash, you'll lose up to 15 minutes' work.
-
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 ?
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.
regards,
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
On Mon, 30 Jul 2001, Tony Lill wrote:
> Do any of the current batch of journalling filesystems NOT diddle the
> disk every 5 seconds? I've tried reiser and ext3 and they're both
> antithetic to spinning down the disk. Any plans to fix this bug in
> future kernels?
are you sure this is a product of the journal and not the vm? a machine
with 1gig memory doing nothing (<25% physmem used) and ext2 has disk
accesses ever few minutes too.
justin
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.
-
My laptop works quite well with reiserfs, maybe you have some program
that is doing the diddling? Once my disk goes to sleep, it stays asleep
until I do something that isn't in the cache or needs to be written out
of the cache.
David
Tony Lill wrote:
>Do any of the current batch of journalling filesystems NOT diddle the
>disk every 5 seconds? I've tried reiser and ext3 and they're both
>antithetic to spinning down the disk. Any plans to fix this bug in
>future kernels?
>--
>Tony Lill, [email protected]
>President, A. J. Lill Consultants fax/data (519) 650 3571
>539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
>--------------- http://www.ajlc.waterloo.on.ca/ ----------------
>"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, 30 Jul 2001, Justin Guyett wrote:
> On Mon, 30 Jul 2001, Tony Lill wrote:
>
> > Do any of the current batch of journalling filesystems NOT diddle the
> > disk every 5 seconds? I've tried reiser and ext3 and they're both
> > antithetic to spinning down the disk. Any plans to fix this bug in
> > future kernels?
>
> are you sure this is a product of the journal and not the vm? a machine
> with 1gig memory doing nothing (<25% physmem used) and ext2 has disk
> accesses ever few minutes too.
that's not my experience. i use noatime, i've disabled atd and selected
crontab entries, and i've got enough RAM to avoid paging. the disk will
stay spinned down for hours (usually until i touch netscape). the system
is based on redhat 6.1 (2.2 kernel).
-dean