From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Kirill Tkhai <ktkhai@virtuozzo.com>,
tytso@mit.edu, viro@zeniv.linux.org.uk, adilger.kernel@dilger.ca,
snitzer@redhat.com, jack@suse.cz, ebiggers@google.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 0/5] fs, ext4: Physical blocks placement hint for fallocate(0): fallocate2(). TP defrag.
Date: Thu, 27 Feb 2020 16:09:45 +0530 [thread overview]
Message-ID: <20200227103952.34ADB42042@d06av24.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <158272427715.281342.10873281294835953645.stgit@localhost.localdomain>
> fallocate() goes thru standard blocks allocator, which try to behave very
> good for life allocation cases: block placement and future file size
> prediction, delayed blocks allocation, etc. But it almost impossible
> to allocate blocks from specified place for our specific case. The only
> ext4 block allocator option possible to use is that the allocator firstly
> tries to allocate blocks from the same block group, that inode is related to.
> But this is not enough for effective files compaction.
>
> This patchset implements an extension of fallocate():
>
> fallocate2(int fd, int mode, loff_t offset, loff_t len,
> unsigned long long physical)
>
> The new argument is @physical offset from start of device, which is must
> for block allocation. In case of [@physical, @physical + len] block range
> is available for allocation, the syscall assigns the corresponding extent/
> extents to inode. In case of the range or its part is occupied, the syscall
> returns with error (maybe, smaller range will be allocated. The behavior
> is the same as when fallocate() meets no space in the middle).
Doesn't this interface kills the whole philosophy of letting filesystems
to decide which block it sees as most fit for allocation. IMHO user
passing over actual physical location from where the FS should allocate,
does not sound like a good interface.
-ritesh
next prev parent reply other threads:[~2020-02-27 10:40 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
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 ` Ritesh Harjani [this message]
2020-02-28 7:07 ` [PATCH RFC 0/5] fs, ext4: Physical blocks placement hint for fallocate(0): fallocate2(). TP defrag 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=20200227103952.34ADB42042@d06av24.portsmouth.uk.ibm.com \
--to=riteshh@linux.ibm.com \
--cc=adilger.kernel@dilger.ca \
--cc=dmonakhov@gmail.com \
--cc=ebiggers@google.com \
--cc=enwlinux@gmail.com \
--cc=jack@suse.cz \
--cc=khazhy@google.com \
--cc=krisman@collabora.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
--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).