From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [PATCH] various allocator optimizations Date: 12 Mar 2003 08:31:16 -0500 Message-ID: <1047475876.8215.507.camel@tiny.suse.com> References: <1047400482.8215.312.camel@tiny.suse.com> <20030311194205.A4493@namesys.com> <1047403968.8219.337.camel@tiny.suse.com> <3E6E584D.4080809@namesys.com> <1047421551.8219.448.camel@tiny.suse.com> <3E6E674E.4040305@namesys.com> <1047433739.8215.487.camel@tiny.suse.com> <20030312101222.A8452@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <20030312101222.A8452@namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii" To: Oleg Drokin Cc: Hans Reiser , reiserfs-list@namesys.com On Wed, 2003-03-12 at 02:12, Oleg Drokin wrote: > > > No, it uses the left neighbor in the tree. Please correct me if I am > > > wrong, because if I am wrong we have a bug. > > It uses the left neighbor in the tree once the file has a starting > > block. But the first starting block comes by searching from block #0. > > No, this is not correct. > We look at the left neighbor. > See the get_left_neighbor() in bitmap.c, > first we make the search_start to be a block number of last path > element (if there is path at all of course which may be not there in some > cases), ans then check if we are allocating indirect block and if there is > non zero element in current indirect item in path, if there is non-zero element, > we take it as new search_start, otherwise it still contains blocknumber of > left neighbor. Right, I missed the hint->search_start = bh->b_blocknr for when we don't find an indirect item. This is better, so the search will start from the bh with the stat data for a new file, but it depends on the last path element being in a good position relative to the rest of the files in the directory. -chris