From: Dave Chinner <david@fromorbit.com>
To: Jayashree Mohan <jayashree2912@gmail.com>
Cc: linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: Behavior of falloc collapse range when preceded by falloc keep size : Possible eof block loss
Date: Thu, 15 Feb 2018 08:48:00 +1100 [thread overview]
Message-ID: <20180214214800.GH7000@dastard> (raw)
In-Reply-To: <CA+EzBbBtpD=shOwnWLwTfkb-mmyaznndGNL3saSEobX0uT7MfA@mail.gmail.com>
On Wed, Feb 14, 2018 at 10:56:31AM -0600, Jayashree Mohan wrote:
> Hi,
>
> I am Jayashree Mohan, a PhD student at the University of Texas at
> Austin, working with Prof. Vijay Chidambaram. I've been working on the
> Crashmonkey project, which is a test harness for file system crash
> consistency checks[1].
>
> While trying to reproduce some of the reported bugs on filesystems
> using CrashMonkey we stumbled upon the following issue:
>
> Whenever we have a collapse_range operation that follows fallocate
> with keep_size that allocated blocks beyond the end-of-file, the eof
> blocks are lost due to the collapse_range operation in f2fs and xfs.
.....
> If we didn't have the keep_size option with fallocate in step 2, then
> we see the xfs_bmap after step 3 to be
> 0: [0..223]: 160..383
> 1: [224..823]: 416..1015
> 2: [824..831]: 1016..1023
>
> This clearly shows, the blocks allocated beyond the eof are lost
> during the collapse_range operation, if keep_size was specified while
> allocating these blocks. This behavior is seen in both f2fs and xfs,
> while ext4 seems to preserve the allocated blocks. All these were
> tested on linux kernel 4.15. Shouldn't f2fs and xfs also behave like
> ext4?
Yup, XFS trims post-eof blocks before a collapse because:
/*
* Trim eofblocks to avoid shifting uninitialized post-eof preallocation
* into the accessible region of the file.
*/
if (xfs_can_free_eofblocks(ip, true)) {
error = xfs_free_eofblocks(ip);
if (error)
return error;
}
we can retain uninitialised extents beyond EOF. I think that
uninitialised preallocation beyond EOF cannot occur in ext4 (i.e.
it can only have unwritten extents beyond EOF) but you'll need to
check that.
IOWs, ext4 needs to be considered "potentially dangerous" in
terms of it's behaviour here, and that both XFS and f2fs are doing
the obviously safe thing.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2018-02-14 21:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 16:56 Behavior of falloc collapse range when preceded by falloc keep size : Possible eof block loss Jayashree Mohan
2018-02-14 21:48 ` Dave Chinner [this message]
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=20180214214800.GH7000@dastard \
--to=david@fromorbit.com \
--cc=jayashree2912@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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).