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

[Jeff Mahoney <jeffm@suse.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBGSwaLPWxlyuTD7IRAkwWAJ4uPTDcvSAgKpJm6KA4KMcSDb5iKwCcDjKN
cdMveSkc/zsVdGzsZvx5SsM=
=l45w
-----END PGP SIGNATURE-----