[RFC][PATCH 0/3] ext4: inode preferred block allocation

[RFC][PATCH 0/3] ext4: inode preferred block allocation

[Kazuya Mio]

Hi,

We implemented new two ioctls to allocate preferred blocks using inode PA.
The old implementation idea is the following (b).
http://marc.info/?l=linux-ext4&m=124962738211206&w=4

One is EXT4_IOC_CONTROL_PA that is to create or discard inode PA, and the
other is EXT4_IOC_GET_PA that is to get inode PA information.

1. EXT4_IOC_CONTROL_PA

   EXT4_IOC_CONTROL_PA is used to create new inode PA, or to discard all inode
   PAs in the target inode. This means that we will be able to allocate
   the blocks we want.
   We have a plan to add a new feature to e4defrag with these ioctls. This
   feature improves read throughput when we read the files in the same
   directory by reallocating target files near their parent directory.

2. EXT4_IOC_GET_PA

   EXT4_IOC_GET_PA is used to get inode PA information.

Moreover, when we create an inode PA, ext4_mb_new_inode_pa() merges
contiguous inode PA if possible.

This patch set consists of the following three patches. They can be applied to
the ext4 patch queue:
commit: 1dea5b6f540ad056d51d11cda71fa757cb44cbc4

[RFC][PATCH 0/3] ext4: inode preferred block allocation
[RFC][PATCH 1/3] ext4: add EXT4_IOC_CONTROL_PA to create/discard inode PA
[RFC][PATCH 2/3] ext4: sort and merge inode PA
[RFC][PATCH 3/3] ext4: add EXT4_IOC_GET_PA to get inode PA information

Any comments are very welcome.

Best regards,
Kazuya Mio

Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

[Andi Kleen]

Kazuya Mio <k-mio@sx.jp.nec.com> writes:


> We implemented new two ioctls to allocate preferred blocks using inode PA.
> The old implementation idea is the following (b).
> http://marc.info/?l=linux-ext4&m=124962738211206&w=4

I had to read until patch 3/3 to find out what a "PA" actually is.
It might make the patch descriptions more clearer if it was spelled
out at least once in each.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

[Kazuya Mio]

Hi Andi,

2010/04/16 0:11, Andi Kleen wrote:
> Kazuya Mio<k-mio@sx.jp.nec.com>  writes:
> 
> 
>> We implemented new two ioctls to allocate preferred blocks using inode PA.
>> The old implementation idea is the following (b).
>> http://marc.info/?l=linux-ext4&m=124962738211206&w=4
> 
> I had to read until patch 3/3 to find out what a "PA" actually is.
> It might make the patch descriptions more clearer if it was spelled
> out at least once in each.

Thank you for informing me.
I will take care not to abbreviate the first "preallocation" to "PA".

Best regards,
Kazuya Mio

Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

[Greg Freemyer]

Dmitry added to cc because of use case at the bottom discussing ProjectID

2010/4/14 Kazuya Mio <k-mio@sx.jp.nec.com>:
> Hi,
>
> We implemented new two ioctls to allocate preferred blocks using inode PA.
> The old implementation idea is the following (b).
> http://marc.info/?l=linux-ext4&m=124962738211206&w=4
>
> One is EXT4_IOC_CONTROL_PA that is to create or discard inode PA, and the
> other is EXT4_IOC_GET_PA that is to get inode PA information.
>
> 1. EXT4_IOC_CONTROL_PA
>
>   EXT4_IOC_CONTROL_PA is used to create new inode PA, or to discard all inode
>   PAs in the target inode. This means that we will be able to allocate
>   the blocks we want.
>   We have a plan to add a new feature to e4defrag with these ioctls. This
>   feature improves read throughput when we read the files in the same
>   directory by reallocating target files near their parent directory.
>
> 2. EXT4_IOC_GET_PA
>
>   EXT4_IOC_GET_PA is used to get inode PA information.
>
> Moreover, when we create an inode PA, ext4_mb_new_inode_pa() merges
> contiguous inode PA if possible.
>
> This patch set consists of the following three patches. They can be applied to
> the ext4 patch queue:
> commit: 1dea5b6f540ad056d51d11cda71fa757cb44cbc4
>
> [RFC][PATCH 0/3] ext4: inode preferred block allocation
> [RFC][PATCH 1/3] ext4: add EXT4_IOC_CONTROL_PA to create/discard inode PA
> [RFC][PATCH 2/3] ext4: sort and merge inode PA
> [RFC][PATCH 3/3] ext4: add EXT4_IOC_GET_PA to get inode PA information
>
> Any comments are very welcome.
>
> Best regards,
> Kazuya Mio

Kazuya,

I have a basic understanding how these could be used by e4defrag to
organize stable data blocks / extents, but is the goal to also allow a
working set of dynamic files which allocate new data blocks routinely?

== details / example

Assume I know that files owned by a specific user (such as the apache
daemon) need to be collocated to reduce seek times as pages are
displayed.

After the fact, I can see the e4defrag moving all files with UID
apached into a subset of block groups thus increasing locality and
decreasing seeks.

But what if those files themselves are dynamically being created /
extended and thus allocating new data blocks/extents on the fly.   The
need in that situation would be more along the lines of defining a
preferred block group range for all files with the same UID.  And all
of those files would be provided exactly the same block range.

ie. If we have a 1 TB array, but the heavily used dynamic webserver
pages is only 5 GB, so I want to define a 5 GB block group range to
have those files live in.

Anyway, my main question again is if this patchset is only designed
for after the fact file/data locality organization, or if it is also
designed to support dynamic environments.

fyi: Creating locality groups is the use case I see for Dmitry's
Project ID patchset.  A collection of files that are used together can
be assigned a unique ProjectID and then e4defrag can grow the
knowledge to place them within a locality area on the disk.

But I also can see that new files within a directory would inherit the
ProjectID from the directory, and the data blocks allocated from the
correct locality area from the get go.

Dmitry, I haven't studied your patchset, but does it allow for
ProjectID inheritance from the parent directory?

Thanks
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

[Jan Kara]

On Thu 15-04-10 12:22:38, Greg Freemyer wrote:
<snip>
> fyi: Creating locality groups is the use case I see for Dmitry's
> Project ID patchset.  A collection of files that are used together can
> be assigned a unique ProjectID and then e4defrag can grow the
> knowledge to place them within a locality area on the disk.
> 
> But I also can see that new files within a directory would inherit the
> ProjectID from the directory, and the data blocks allocated from the
> correct locality area from the get go.
> 
> Dmitry, I haven't studied your patchset, but does it allow for
> ProjectID inheritance from the parent directory?
  Yes, ProjectID should be inherited from the parent directory.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

[Kazuya Mio]

2010/04/16 1:22, Greg Freemyer wrote:
> I have a basic understanding how these could be used by e4defrag to
> organize stable data blocks / extents, but is the goal to also allow a
> working set of dynamic files which allocate new data blocks routinely?
> 
> == details / example
> 
> Assume I know that files owned by a specific user (such as the apache
> daemon) need to be collocated to reduce seek times as pages are
> displayed.
> 
> After the fact, I can see the e4defrag moving all files with UID
> apached into a subset of block groups thus increasing locality and
> decreasing seeks.
> 
> But what if those files themselves are dynamically being created /
> extended and thus allocating new data blocks/extents on the fly.   The
> need in that situation would be more along the lines of defining a
> preferred block group range for all files with the same UID.  And all
> of those files would be provided exactly the same block range.

Even if we implement preferred block group range, the problem you said will
occur. Because we don't know how much data will be increased.
If you really want the function, you will be able to materialize your idea by
creating the persistent inode preallocation in struct ext4_sb_info.

I don't have a plan to develop the function of the inode preferred range at
present. This patch has a function enough to realize new feature of e4derag.
Moreover, Andreas said we should not create a second similar mechanism.
http://marc.info/?l=linux-ext4&m=124650093015617&w=4

Best Regards,
Kazuya Mio