From: Bart Samwel <bart@samwel.tk>
To: Dave Johnson <dave-lkml-01@centerclick.org>
Cc: linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [ext3] kjournald writing after each read despite noatime,commit=nnn
Date: Thu, 01 Jan 2009 19:59:52 +0100 [thread overview]
Message-ID: <495D12A8.9030703@samwel.tk> (raw)
In-Reply-To: <18780.62500.100687.402706@wellington.i202.centerclick.org>
Hi Dave,
Dave Johnson wrote:
> Bart Samwel writes:
>> This is the defined behaviour for laptop_mode. Whenever a *physical*
>> READ takes place, this is taken to indicate that the disk is spun up at
>> that time. The laptop_mode functionality then takes that opportunity to
>> sync any dirty data to disk, two seconds (or whatever value you put in
>> /proc/sys/vm/laptop_mode) after the physical disk activity has ceased.
>> The rationale behind this is that you want to sync your stuff when the
>> disk is spun up, and then you want to hold back writing back stuff for a
>> very long while. And the only way it can detect that the disk is spun up
>> is when there is physical disk activity.
>>
>> This is exactly what happens in your case. The READ activity reported by
>> block_dump is *physical* read activity: some data was needed that was
>> not cached in memory. block_dump does not show you what data was
>> retrieved from the ext3 fs *without* having to access the disk, it only
>> shows actual physical disk I/O.
>
> Yep sounds good, but this happens even if there is no dirty data
> needing a sync back to disk.
>
> $ grep 'Dirty\|Write' /proc/meminfo
> Dirty: 0 kB
> Writeback: 0 kB
> WritebackTmp: 0 kB
> $ cat /some/uncached/file >/dev/null
>
> Jan 1 11:43:49 gw kernel: cat(6615): READ block 864408 on hda1
> Jan 1 11:43:51 gw kernel: kjournald(760): WRITE block 2376 on hda1
This looks like it's a generic property of syncing an ext3 file system.
Try turning off laptop_mode and then running "sync". You will probably
see the same behaviour.
> Note, the reason I ask is this is a SSD so just because a physical
> read has taken place recently unneeded writes should be avoided.
>
> Turning laptop_mode to 0, but leaving other settings the same
> resolves the uneeded write:
For your SSD I guess you need to get rid of the
sync-after-disk-activity, but keep the other VM behaviours of
laptop_mode (such as avoiding swapping out pages / writing back dirty
pages in order to free memory as long as it is also possible to just
drop pages that are not dirty).
You can probably achieve this by:
- having a large commit interval etc., like you have now
- setting laptop_mode to a very large value, e.g. a couple of hours.
That will trigger a sync if and only if there has been *no* disk
activity at all for hours on end -- i.e., pretty much never. And the
other write-reducing VM features of laptop_mode will still be enabled.
It would perhaps be a good thing to split these mechanisms into separate
knobs. Write batching (the sync-after-disk-activity stuff and also the
dirty_ratio / dirty_background_ratio changes) are a completely separate
mechanism from write avoidance (the other mechanism I mentioned).
Cheers,
Bart
next prev parent reply other threads:[~2009-01-01 18:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 21:28 [ext3] kjournald writing after each read despite noatime,commit=nnn Dave Johnson
2009-01-01 14:02 ` Bart Samwel
2009-01-01 16:49 ` Dave Johnson
2009-01-01 18:59 ` Bart Samwel [this message]
2009-01-01 19:18 ` Dave Johnson
2009-01-01 19:35 ` Dave Johnson
2009-01-01 20:16 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=495D12A8.9030703@samwel.tk \
--to=bart@samwel.tk \
--cc=dave-lkml-01@centerclick.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.