From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ming Zhang Subject: Re: reiser fs slow on mksf and mount Date: Sat, 27 Aug 2005 18:53:28 -0400 Message-ID: <1125183208.5569.3.camel@localhost.localdomain> References: <1125074717.5549.44.camel@localhost.localdomain> <430F4B91.7030909@namesys.com> <1125076138.5549.65.camel@localhost.localdomain> <1125076558.5549.72.camel@localhost.localdomain> <430F5226.50701@namesys.com> <1125080213.5549.100.camel@localhost.localdomain> <4310BF35.3060603@suse.com> Reply-To: mingz@ele.uri.edu Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <4310BF35.3060603@suse.com> List-Id: Content-Type: text/plain; charset="us-ascii" To: Jeff Mahoney Cc: "Vladimir V. Saveliev" , reiserfs-list@namesys.com On Sat, 2005-08-27 at 15:29 -0400, Jeff Mahoney wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. so u always keep a reference on all bitmap pages and thus they can not be umounted. yes, by this way it can be pretty fast to do any meta-data operation. but what if current RAM can not hold these bitmap. maybe u think if i want to use tens of TB storage, i of course will have 32GB RAM. :P > > 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. ic. this is like a delayed lazy allocation. > > It's a relatively straightforward patch - the error handling I refer to > is how to handle block read failures, which would only occur if your > disk is failing. yes, understandable. thanks! Ming > > - -Jeff > > - -- > Jeff Mahoney > SuSE Labs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFDEL81LPWxlyuTD7IRAnHWAJ9TmL/5ziKt4ObSUR9c/MJps4HydQCfXj0s > Kd4u+V+PYZQydA/YqelyJvo= > =pHCV > -----END PGP SIGNATURE-----