From: Theodore Ts'o <tytso@mit.edu>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Namjae Jeon <namjae.jeon@samsung.com>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
'Ashish Sangwan' <a.sangwan@samsung.com>,
linux-fsdevel@vger.kernel.org,
'linux-ext4' <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v2 0/10] fs: Introduce FALLOC_FL_INSERT_RANGE for fallocate
Date: Mon, 2 Jun 2014 11:02:58 -0400 [thread overview]
Message-ID: <20140602150258.GG30598@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1406021450541.2231@localhost.localdomain>
On Mon, Jun 02, 2014 at 03:06:13PM +0200, Lukáš Czerner wrote:
> > > So what will happen when there is not enough space when "inserting a
> > > range" ? And how should user proceed from there ?
> > If insert range fails with an ENOSPC error, user could use collapse
> > range on the same range to remove the hole.
> > And after freeing more space, he can again try inserting range.
> > Ofcourse, this type of guidance should be properly documented in
> > manpage. When updating fallocate(2) manpage, I will keep in mind to
> > describe ENOSPC handling.
>
> Why collapse ? The hole is already there right ? Why not just use
> fallocate to allocate the space for the hole. And that's my point
> actually. Why not do it this way in the first place, because this is
> really counterintuitive.
It's worse than that. It's possible that the reason why you got the
ENOSPC warning was because the operation to move the extents down
required allocating a block, and it was *that* block allocation which
failed. So it's not deterministic whether or not the file's extent
mappings were modified after a ENOSPC error, and so it's not clear
whether or not a collapse_range function will undo the range that had
been inserted --- or whether it ends up deleting existing data blocks.
In generally, you really want system calls to have all-or-nothing
effects, where if the system call returns an error, the state of the
file has not been changed. And for that reason, I agree with Lukáš
that it is really a good idea to decouple moving the blocks down, and
allocating space --- and to make sure that if there is any failure
while inserting the range, the state of the file is not modified at all.
Cheers,
- Ted
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-02 15:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 10:23 [PATCH v2 0/10] fs: Introduce FALLOC_FL_INSERT_RANGE for fallocate Namjae Jeon
2014-05-30 10:54 ` Lukáš Czerner
2014-05-31 7:40 ` Namjae Jeon
2014-06-02 10:13 ` Lukáš Czerner
2014-06-02 11:52 ` Namjae Jeon
2014-06-02 13:06 ` Lukáš Czerner
2014-06-02 15:02 ` Theodore Ts'o [this message]
2014-06-04 4:57 ` Namjae Jeon
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=20140602150258.GG30598@thunk.org \
--to=tytso@mit.edu \
--cc=a.sangwan@samsung.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=xfs@oss.sgi.com \
/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).