Message-ID: <ef3f2efc-88b9-401e-7b01-5e40a2412f5b@virtuozzo.com>
Date:   Thu, 27 Feb 2020 13:42:08 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Christoph Hellwig <hch@...radead.org>
Cc:     tytso@....edu, viro@...iv.linux.org.uk, adilger.kernel@...ger.ca,
        snitzer@...hat.com, jack@...e.cz, ebiggers@...gle.com,
        riteshh@...ux.ibm.com, krisman@...labora.com, surajjs@...zon.com,
        dmonakhov@...il.com, mbobrowski@...browski.org, enwlinux@...il.com,
        sblbir@...zon.com, khazhy@...gle.com, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH RFC 5/5] ext4: Add fallocate2() support

On 27.02.2020 09:59, Konstantin Khlebnikov wrote:
> On 26/02/2020 23.05, Kirill Tkhai wrote:
>> On 26.02.2020 18:55, Christoph Hellwig wrote:
>>> On Wed, Feb 26, 2020 at 04:41:16PM +0300, Kirill Tkhai wrote:
>>>> This adds a support of physical hint for fallocate2() syscall.
>>>> In case of @physical argument is set for ext4_fallocate(),
>>>> we try to allocate blocks only from [@phisical, @physical + len]
>>>> range, while other blocks are not used.
>>>
>>> Sorry, but this is a complete bullshit interface.  Userspace has
>>> absolutely no business even thinking of physical placement.  If you
>>> want to align allocations to physical block granularity boundaries
>>> that is the file systems job, not the applications job.
>>
>> Why? There are two contradictory actions that filesystem can't do at the same time:
>>
>> 1)place files on a distance from each other to minimize number of extents
>>    on possible future growth;
>> 2)place small files in the same big block of block device.
>>
>> At initial allocation time you never know, which file will stop grow in some future,
>> i.e. which file is suitable for compaction. This knowledge becomes available some time later.
>> Say, if a file has not been changed for a month, it is suitable for compaction with
>> another files like it.
>>
>> If at allocation time you can determine a file, which won't grow in the future, don't be afraid,
>> and just share your algorithm here.
>>
>> In Virtuozzo we tried to compact ext4 with existing kernel interface:
>>
>> https://github.com/dmonakhov/e2fsprogs/blob/e4defrag2/misc/e4defrag2.c
>>
>> But it does not work well in many situations, and the main problem is blocks allocation
>> in desired place is not possible. Block allocator can't behave excellent for everything.
>>
>> If this interface bad, can you suggest another interface to make block allocator to know
>> the behavior expected from him in this specific case?
> 
> Controlling exact place is odd. I suppose main reason for this that defragmentation
> process wants to control fragmentation during allocating new space.
> 
> Maybe flag FALLOC_FL_DONT_FRAGMENT (allocate exactly one extent or fail) could solve that problem?
>
> Defragmentator could try allocate different sizes and automatically balance fragmentation factor
> without controlling exact disk offsets. Also it could reserve space for expected file growth.

I don't think this will helps. The problem is not in allocation a single extent (fallocate() already
tries to allocate as small number of extents as possible), but in that it's impossible to allocate it
in desired bounds. Say, you have 1Mb discard granuality on block device and two files in different
block device clusters: one is 4Kb of length, another's size is 1Mb-4Kb. The biggest file is situated
on the start of block device cluster:

[      1Mb cluster0       ][      1Mb cluster1     ]
[****BIG_FILE****|free 4Kb][small_file|free 1Mb-4Kb]

The best defragmentation will be to move small_file into free 4Kb of cluster0. Allocation of single
extent does not help here: you have to allocate very big bunch of such extents in cycle before
allocator returns you desired block, and then it's need to return the rest of extents back. This
has very bad performance.

Powered by blists - more mailing lists