where P(len) represents the probability of the success allocation for an
exact *len* length of extent.
To prove that, Imagine we have to allocate two extent at len 1 and 4 in af 0,
if we can allocate len 4 in af 0, then we can allocate len 1 in af 0.
but,
if we can allocate len 1 in af 1, we may not allocate len 4 in af 0.
So, P(len1) <= P(len2).
That means it will naturally form a layer of different len. like:
+------------------------+
| 8 |
af 2 | 1 8 8 1 |
| 1 1 |
+------------------------+
| |
| 4 |
| 4 |
af 1 | 4 1 |
| 1 4 |
| 4 |
+------------------------+
| |
| 1 1 1 |
| |
| 1 |
| 1 1 4 1 |
af 0 | 1 |
| 1 |
| 1 |
| 1 |
| |
+------------------------+
So there is no need so provide extra preference control info for
an allocation. It will naturally find where it should go.
So without the extra need of changing the application source code.
> > We did some tests verify it. You can verify it yourself
> > by running the following the command:
> >
> > 1. Create an 1g sized img file and formated it as xfs:
> > dd if=/dev/zero of=test.img bs=1M count=1024
> > mkfs.xfs -f test.img
> > sync
> > 2. Make a mount directory:
> > mkdir mnt
> > 3. Run the auto_frag.sh script, which will call another scripts
> > frag.sh. These scripts will be attached in the mail.
> > To enable the AF, run:
> > ./auto_frag.sh 1
> > To disable the AF, run:
> > ./auto_frag.sh 0
> >
> > Please feel free to communicate with us if you have any thoughts
> > about these problems.
>
> We already have inode/metadata preferred allocation groups that
> are avoided for data allocation if at all possible. This is how we
> keep space free below 1TB for inodes when the inode32 allocator has
> been selected. See xfs_perag_prefers_metadata().
>
> Perhaps being able to control this preference from userspace (e.g.
> via xfs_spaceman commands through ioctls and/or sysfs knobs) would
> acheive the same results with a minimum of code and/or policy
> changes. i.e. if AG0 is preferred for metadata rather than data,
> we won't allocate data in it until all higher AGs are largely full.
>
> -Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
