From: Oleg Drokin <green@namesys.com>
To: Vitaly Fertman <vitaly@namesys.com>,
berthiaume_wayne@emc.com, philippe.gramoulle@mmania.com,
reiserfs-list@namesys.com
Subject: Re: reiserfsprogs 3.6.5-pre2 release.
Date: Thu, 27 Feb 2003 09:11:13 +0300 [thread overview]
Message-ID: <20030227091113.A28643@namesys.com> (raw)
In-Reply-To: <20030226122144.U1373@schatzie.adilger.int>
Hello!
On Wed, Feb 26, 2003 at 12:21:44PM -0700, Andreas Dilger wrote:
> > tests shown that almost all the time was spent on reading bitmap blocks.
> > And the same reading is done at mount time actually.
> It would be interesting to see if reiserfsck immediately followed by mount
> (which is the normal boot behaviour) takes any longer than just the mount.
Two subsequent fsck -a takes twice the time. Almost (+- 2 secs of 48)
> Oleg posted that the block device cache is flushed upon last close, but I
> don't think that is totally true. It _was_ true for a short while, but
It is. You can trivially verify that.
> it was rather annoying and I think Al Viro fixed that so that the block
> device cache was "lazily" dropped, so you would keep it if you re-opened
> the device shortly after closing it.
No, I do not think so. Invalidate inode pages (or whatever) is called on
last device close. Anyway think of two fscks on two filesystems, then mounting.
Though last time I played with stock SuSE kernels (not so long ago), they had
this behavior turned off and cache survived device close.
> I suppose the other way to test it would be to run 2 "reiserfsck -a"
> in a row.
Yes, Philippe did this for us already.
Bye,
Oleg
next prev parent reply other threads:[~2003-02-27 6:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-26 15:12 reiserfsprogs 3.6.5-pre2 release berthiaume_wayne
2003-02-26 16:14 ` Vitaly Fertman
2003-02-26 18:59 ` Hans Reiser
2003-02-26 19:21 ` Andreas Dilger
2003-02-26 23:40 ` Philippe Gramoullé
2003-02-27 6:11 ` Oleg Drokin [this message]
2003-02-26 23:49 ` Anders Widman
2003-02-27 6:13 ` Oleg Drokin
-- strict thread matches above, loose matches on Subject: below --
2003-02-25 16:25 berthiaume_wayne
2003-02-25 16:41 ` Vitaly Fertman
2003-02-25 13:50 Vitaly Fertman
2003-02-25 14:12 ` Vitaly Fertman
2003-02-26 0:54 ` Philippe Gramoullé
2003-02-26 7:29 ` Oleg Drokin
2003-02-26 8:23 ` Philippe Gramoullé
2003-02-26 11:27 ` Hans Reiser
2003-02-26 12:14 ` Anders Widman
2003-02-26 12:24 ` Oleg Drokin
2003-02-26 12:34 ` Anders Widman
2003-02-26 12:42 ` Oleg Drokin
2003-03-05 0:50 ` Zygo Blaxell
2003-03-05 17:48 ` Dieter Nützel
2003-03-05 18:10 ` Vitaly Fertman
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=20030227091113.A28643@namesys.com \
--to=green@namesys.com \
--cc=berthiaume_wayne@emc.com \
--cc=philippe.gramoulle@mmania.com \
--cc=reiserfs-list@namesys.com \
--cc=vitaly@namesys.com \
/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.