Re: Why larger extent counts aren't necessarily bad (was Re: Odd Block allocation behavior on Reiser3)

[Hans Reiser <reiser@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