All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: frankcmoeller@arcor.de
Cc: linux-ext4@vger.kernel.org
Subject: Re: Ext4: Slow performance on first write after mount
Date: Sun, 19 May 2013 10:00:23 -0400	[thread overview]
Message-ID: <20130519140023.GB7183@thunk.org> (raw)
In-Reply-To: <1679869241.585607.1368809483337.JavaMail.ngmail@webmail12.arcor-online.net>

On Fri, May 17, 2013 at 06:51:23PM +0200, frankcmoeller@arcor.de wrote:
> - Why do you throw away buffer cache and don't store it on disk during umount? The initialization of the buffer cache is quite awful for application which need a specific write throughput.
> - A workaround would be to read whole /proc/.../mb_groups file right after every mount. Correct?

Simply adding "cat /proc/fs/<dev>/mb_groups > /dev/null" to one of the
/etc/init.d scripts, or to /etc/rc.local is probably the simplest fix,
yes.

> - I can try to add a mount option to initialize the cache at mount time. Would you be interested in such a patch?

Given the simple nature of the above workaround, it's not obvious to
me that trying to make file system format changes, or even adding a
new mount option, is really worth it.  This is especially true given
that mount -a is sequential so if there are a large number of big file
systems, using this as a mount option would be slow down the boot
significantly.  It would be better to do this parallel, which you
could do in userspace much more easily using the "cat
/proc/fs/<dev>/mb_groups" workaround.

> - I can see (see debug output) that the call of ext4_wait_block_bitmap in mballoc.c line 848 takes during buffer cache initialization the longest time (some 1/100 of a second). Can this be improved?

The delay is caused purely by I/O delay, so short of replacing the HDD
with a SSD, not really....

Regards,

						- Ted

  parent reply	other threads:[~2013-05-19 14:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17 16:51 Ext4: Slow performance on first write after mount frankcmoeller
2013-05-17 21:18 ` Sidorov, Andrei
2013-05-19 14:00 ` Theodore Ts'o [this message]
2013-05-20  6:39   ` Andreas Dilger
2013-05-20 11:46     ` Theodore Ts'o
     [not found]       ` <D1047C91-765D-4EBD-A6CC-869DF0D5AD90@dilger.ca>
2013-05-21 18:02         ` Aw: " frankcmoeller
2013-05-22  0:27           ` Andreas Dilger
2013-05-20 12:37     ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2013-05-19 10:01 Aw: " frankcmoeller
2013-05-19 13:00 ` Aw: " frankcmoeller
2013-05-20  7:04   ` Andreas Dilger

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=20130519140023.GB7183@thunk.org \
    --to=tytso@mit.edu \
    --cc=frankcmoeller@arcor.de \
    --cc=linux-ext4@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.