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
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Namjae Jeon <namjae.jeon@samsung.com>,
"'Dave Chinner'" <david@fromorbit.com>,
"'linux-ext4'" <linux-ext4@vger.kernel.org>,
xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
"'Ashish Sangwan'" <a.sangwan@samsung.com>
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
next prev parent reply other threads:[~2014-06-02 15:02 UTC|newest]
Thread overview: 16+ 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-08 10:23 ` Namjae Jeon
2014-05-30 10:54 ` Lukáš Czerner
2014-05-30 10:54 ` Lukáš Czerner
2014-05-31 7:40 ` Namjae Jeon
2014-05-31 7:40 ` Namjae Jeon
2014-06-02 10:13 ` Lukáš Czerner
2014-06-02 10:13 ` Lukáš Czerner
2014-06-02 11:52 ` Namjae Jeon
2014-06-02 11:52 ` Namjae Jeon
2014-06-02 13:06 ` Lukáš Czerner
2014-06-02 13:06 ` Lukáš Czerner
2014-06-02 15:02 ` Theodore Ts'o [this message]
2014-06-02 15:02 ` Theodore Ts'o
2014-06-04 4:57 ` Namjae Jeon
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.