All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Iversen <chrivers@iversen-net.dk>
To: reiserfs-list@namesys.com
Subject: Re: reiser fs slow on mksf and mount
Date: Sat, 27 Aug 2005 23:45:09 +0200	[thread overview]
Message-ID: <200508272345.09417.chrivers@iversen-net.dk> (raw)
In-Reply-To: <4310BF35.3060603@suse.com>

On Saturday 27 August 2005 21:29, Jeff Mahoney wrote:
> Ming Zhang wrote:
> > On Fri, 2005-08-26 at 21:32 +0400, Vladimir V. Saveliev wrote:
> >
> >
> > one more question about this bitmap blocks
> >
> > are this bitmap data is pinned into system thus will not be swapped out?
>
> Yes, any buffers/pages with active reference counts are kept in memory.
> Since the current reiserfs bitmap implementation keeps a reference until
> filesystem umount, the bitmaps are pinned.
>
> My dynamic bitmap patch fixes both of the problems you've posed so far.
> Mount time is reduced to O(1) time, since only the superblock and root
> node are read at mount time. On my system, it's something along the
> lines of 0.2s. Memory consumption is reduced also, because the bitmap
> block is released after the allocation/free that required it is complete.

I've been reading about this patch with quite some interest. Would you say 
it's stable enough for daily use? I have a terabyte array that takes forever 
to mount, and probably uses quite a bit of memory too.

Another thing is that it can easily take several seconds to do "ls -l" on a 
directory with a 0-10 GB data in it. Is that normal? There's usually less 
than 50 files of test data, ranging in size from 200MB to 900MB. I've 
disabled atime updates, but that didn't help much. The controller and disks 
are plenty fast, so I feel something is amiss. 

-- 
Regards,
Christian Iversen

  reply	other threads:[~2005-08-27 21:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-26 16:45 reiser fs slow on mksf and mount Ming Zhang
2005-08-26 17:04 ` Vladimir V. Saveliev
2005-08-26 17:08   ` Ming Zhang
2005-08-26 17:15     ` Ming Zhang
2005-08-26 17:32       ` Vladimir V. Saveliev
2005-08-26 18:07         ` Ming Zhang
2005-08-26 18:16         ` Ming Zhang
2005-08-27 19:29           ` Jeff Mahoney
2005-08-27 21:45             ` Christian Iversen [this message]
2005-08-27 21:55               ` David Masover
2005-08-29 19:44                 ` Hans Reiser
2005-08-27 22:54               ` Ming Zhang
2005-08-29 15:07               ` Jeff Mahoney
2005-08-27 22:53             ` Ming Zhang
2005-08-28  0:01               ` Jeff Mahoney
2005-08-28 15:40                 ` Ming Zhang
2005-08-28 18:44                   ` Jeff Mahoney
2005-08-29 12:39                     ` Ming Zhang
2005-08-29 14:26                       ` Jeff Mahoney
2005-08-29 14:41                         ` Ming Zhang
2005-08-29 14:51                           ` Jeff Mahoney
2005-08-29 15:20                             ` Ming Zhang
2005-08-29 15:28                               ` Jeff Mahoney
2005-08-29 15:37                                 ` Ming Zhang
2005-08-29 19:40             ` Hans Reiser
2005-08-29 19:44               ` Jeff Mahoney
2005-08-29 19:53                 ` Hans Reiser
2005-08-29 16:44   ` Ming Zhang

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=200508272345.09417.chrivers@iversen-net.dk \
    --to=chrivers@iversen-net.dk \
    --cc=reiserfs-list@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.