From: Brian Foster <bfoster@redhat.com>
To: Bill McDuck <billmcdave@gmail.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Significantly longer fallocate times with Flag Unwritten Extents disabled
Date: Mon, 6 Mar 2017 08:05:01 -0500 [thread overview]
Message-ID: <20170306130500.GA3223@bfoster.bfoster> (raw)
In-Reply-To: <CAEOfVRnuTD0AWNSE+_-3KVL_xTcgrq5Q8+mm0mEQYua7gaGQiQ@mail.gmail.com>
On Mon, Mar 06, 2017 at 12:02:01PM +0000, Bill McDuck wrote:
> Hello.
>
> I have been testing the performance of XFS with "Flag Unwritten
> Extents" enabled and disabled.
>
> For security reasons I know XFS flags all unwritten extents by
> default, so that uninitialized disk space cannot be read by the user.
> In my application I actually want to have access to this uninitialized
> disk space. I have been modifying the superblocks using xfs_repair to
> enable this functionality.
>
> Interestingly, I have found that creating a 10 GB file using fallocate
> is significantly slower with unwritten flag extents disabled. For
> instance, creating a 10GB file takes 32 seconds on my (slow) machine,
> whereas with the flag enabled, the process is almost instantaneous.
>
> Does anyone know why creating an uninitialized file is so much slower
> when the unwritten extents flag functionality is disabled? I know
> that the disk is not being initialized to zero, as I can read back non
> zero content.
>
On a quick fallocate test, it is actually zeroing out the blocks in the
post-fallocate setattr (to set the inode size). If the fallocate changes
the size of the file, we call xfs_vn_setattr_size(). That eventually
calls an xfs_zero_range() on the blocks between the old eof and new eof.
I suspect this occurs regardless of whether you've disabled the
unwritten flag bit, but the iomap_zero_range() codepath can shortcut
through the extents when they are marked as unwritten. You can get
around this by truncating the file before the fallocate.
BTW, if you are hitting this behavior and can read non-zero data
afterwards that you are sure you have not written or is not already
inside eof at the time of the falloc, you may be hitting a bug. Please
verify and follow up with details of your test case if you can indeed
reproduce that behavior. I don't reproduce it in my test env (without a
truncate first)..
Brian
> For my application I'm interested in creating large uninitialised
> files quickly, so I'm very interested to know what additional
> operations are being performed with the flagging disabled.
>
> Thanks for the help.
>
> Bill.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-03-06 13:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-06 12:02 Significantly longer fallocate times with Flag Unwritten Extents disabled Bill McDuck
2017-03-06 13:05 ` Brian Foster [this message]
2017-03-08 15:56 ` Christoph Hellwig
2017-03-08 16:48 ` Bill
2017-03-08 21:50 ` Dave Chinner
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=20170306130500.GA3223@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=billmcdave@gmail.com \
--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).