From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: tytso@mit.edu, viro@zeniv.linux.org.uk, adilger.kernel@dilger.ca,
snitzer@redhat.com, jack@suse.cz, ebiggers@google.com,
riteshh@linux.ibm.com, krisman@collabora.com, surajjs@amazon.com,
dmonakhov@gmail.com, mbobrowski@mbobrowski.org,
enwlinux@gmail.com, sblbir@amazon.com, khazhy@google.com,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC 5/5] ext4: Add fallocate2() support
Date: Wed, 26 Feb 2020 23:05:23 +0300 [thread overview]
Message-ID: <06f9b82c-a519-7053-ec68-a549e02c6f6c@virtuozzo.com> (raw)
In-Reply-To: <20200226155521.GA24724@infradead.org>
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?
Kirill
next prev parent reply other threads:[~2020-02-26 20:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 13:40 [PATCH RFC 0/5] fs, ext4: Physical blocks placement hint for fallocate(0): fallocate2(). TP defrag Kirill Tkhai
2020-02-26 13:40 ` [PATCH RFC 1/5] fs: Add new argument to file_operations::fallocate() Kirill Tkhai
2020-02-26 13:41 ` [PATCH RFC 2/5] fs: Add new argument to vfs_fallocate() Kirill Tkhai
2020-02-26 13:41 ` [PATCH RFC 3/5] fs: Add fallocate2() syscall Kirill Tkhai
2020-02-26 13:41 ` [PATCH RFC 4/5] ext4: Prepare ext4_mb_discard_preallocations() for handling EXT4_MB_HINT_GOAL_ONLY Kirill Tkhai
2020-02-26 13:41 ` [PATCH RFC 5/5] ext4: Add fallocate2() support Kirill Tkhai
2020-02-26 15:55 ` Christoph Hellwig
2020-02-26 20:05 ` Kirill Tkhai [this message]
2020-02-26 21:51 ` Andreas Dilger
2020-02-27 12:24 ` Kirill Tkhai
2020-02-28 15:35 ` Andreas Dilger
2020-02-28 21:16 ` Dave Chinner
2020-02-29 20:12 ` Andreas Dilger
2020-03-01 0:06 ` Dave Chinner
2020-03-02 10:33 ` Kirill Tkhai
2020-03-02 11:07 ` Kirill Tkhai
2020-02-27 6:59 ` Konstantin Khlebnikov
2020-02-27 10:42 ` Kirill Tkhai
2020-02-27 7:33 ` Dave Chinner
2020-02-27 11:12 ` Kirill Tkhai
2020-02-27 21:56 ` Dave Chinner
2020-02-28 12:41 ` Kirill Tkhai
2020-02-29 22:41 ` Dave Chinner
2020-03-02 10:17 ` Kirill Tkhai
2020-02-27 10:39 ` [PATCH RFC 0/5] fs, ext4: Physical blocks placement hint for fallocate(0): fallocate2(). TP defrag Ritesh Harjani
2020-02-28 7:07 ` xiaohui li
2020-02-28 12:46 ` Kirill Tkhai
2020-03-02 16:56 ` Theodore Y. Ts'o
2020-03-03 9:57 ` Kirill Tkhai
2020-03-03 16:55 ` Theodore Y. Ts'o
2020-03-03 17:36 ` Kirill Tkhai
2020-03-11 19:26 ` Andreas Dilger
2020-03-11 20:29 ` Kirill Tkhai
2020-03-12 0:31 ` Andreas Dilger
2020-03-12 9:23 ` Kirill Tkhai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06f9b82c-a519-7053-ec68-a549e02c6f6c@virtuozzo.com \
--to=ktkhai@virtuozzo.com \
--cc=adilger.kernel@dilger.ca \
--cc=dmonakhov@gmail.com \
--cc=ebiggers@google.com \
--cc=enwlinux@gmail.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=khazhy@google.com \
--cc=krisman@collabora.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
--cc=riteshh@linux.ibm.com \
--cc=sblbir@amazon.com \
--cc=snitzer@redhat.com \
--cc=surajjs@amazon.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).