From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: Why larger extent counts aren't necessarily bad (was Re: Odd Block allocation behavior on Reiser3) Date: Thu, 09 Sep 2004 10:04:04 -0700 Message-ID: <41408D04.2040803@namesys.com> References: <20040809201939.GA55683@kevlar.burdell.org> <1092083451.10651.218.camel@watt.suse.com> <20040809220459.GA57121@kevlar.burdell.org> <41187657.7030709@namesys.com> <20040810154514.GA67591@kevlar.burdell.org> <41190B5A.7070503@namesys.com> <41192C1A.6080909@suse.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: <41192C1A.6080909@suse.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Jeff Mahoney Cc: Sonny Rao , reiserfs-list@namesys.com Jeff Mahoney wrote: > Hans Reiser wrote: > | Sonny Rao wrote: > > |> Below I made 24 one gigabyte files in sequence > |> All of them are similarly fragmented: > | this could explain some reiser3 performance problems. This is what > | happens when I spend all my time chasing funding and don't spend it > | reviewing code and benchmarks, sigh. > | > | Thanks for spotting this. I would be curious if this is occuring near > | the transition between unformatted nodes and their parents, or something > | else. > > Having a high extent count isn't indicative of fragmentation negatively > affecting performance. In fact, it may be just the opposite. > > I modified filefrag.c to display the displacement between the extents, > and the average extent length. My disk was only 9 GB, so I had to limit > my test to 8 1 GB files, but the results are the same - it's a > sequential write. The number of files has no bearing on the result. > > For this workload, the patterns are so simple, it's distributed almost > perfectly. Even using the skip_busy algorithm by itself (a practice I > warned about over a year ago) produces acceptible results. The results > showed an median extent length of 1023 extents (1 less than contained in > an indirect pointer block), followed by a median extent displacement of > 2 blocks So the filefrag program considers indirect pointer blocks to not be part of the file? Ok, then that is an error of filefrag. Why 2 blocks and not 1? > . For all intents and purposes, the file is contiguous, with > metadata interspersed. > > The pattern of a streaming read/write operation would be like so: > Locate file, locate first indirect pointer block, read blocks, find next > indirect pointer block, read blocks, ... > > In the perceived "ideal" fragementation pattern of 9 fragments > (1024MB/128MB - 4k per bitmap + 8*4k remainder), the metadata is not > interspersed with the file data. It makes the fragmentation extent > number look nice and low, but it really means that every time we need to > read another indirect pointer block, we're seeking outside the data > stream, reading a few blocks (readahead), and seeking back. > > In the fragmentation pattern created using the new allocation algorithms > that Chris and I developed, you'll get a higher fragmentation number, > but the extents are close together, and the pointer blocks are already > read in due to readahead. The "actual" fragmentation is lower than the > "ideal" case above since less seeking is required. > > -Jeff > > -- > Jeff Mahoney > SuSE Labs