From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>, Dilip Simha <nmdilipsimha@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Request for information on bloated writes using Swift
Date: Wed, 3 Feb 2016 09:02:40 -0600 [thread overview]
Message-ID: <56B21690.2070304@sandeen.net> (raw)
In-Reply-To: <20160203083016.GD459@dastard>
On 2/3/16 2:30 AM, Dave Chinner wrote:
> On Tue, Feb 02, 2016 at 11:09:15PM -0800, Dilip Simha wrote:
>> Hi Dave,
>>
>> On Tue, Feb 2, 2016 at 10:37 PM, Dave Chinner <david@fromorbit.com> wrote:
>>
>>> On Tue, Feb 02, 2016 at 07:40:34PM -0800, Dilip Simha wrote:
>>>> Hi Eric,
>>>>
>>>> Thank you for your quick reply.
>>>>
>>>> Using xfs_io as per your suggestion, I am able to reproduce the issue.
>>>> However, I need to falloc for 256K and write for 257K to see this issue.
>>>>
>>>> # xfs_io -f -c "falloc 0 256k" -c "pwrite 0 257k" /srv/node/r1/t1.txt
>>>> # stat /srv/node/r1/t4.txt | grep Blocks
>>>> Size: 263168 Blocks: 1536 IO Block: 4096 regular file
>>>
>>> Fallocate sets the XFS_DIFLAG_PREALLOC on the inode.
>>>
>>> When you writing *past the preallocated area* and do delayed
>>> allocation, the speculative preallocation beyond EOF is double the
>>> size of the extent at EOF. i.e. 512k, leading to 768k being
>>> allocated to the file (1536 blocks, exactly).
>>>
>>
>> Thank you for the details.
>> This is exactly where I am a bit perplexed. Since the reclamation logic
>> skips inodes that have the XFS_DIFLAG_PREALLOC flag set, why did the
>> allocation logic allot more blocks on such an inode?
>
> To store the data you wrote outside the preallocated region, of
> course.
I think what Dilip meant was, why does it do preallocation, not
why does it allocate blocks for the data. That part is obvious
of course. ;)
IOWS, if XFS_DIFLAG_PREALLOC prevents speculative preallocation
from being reclaimed, why is speculative preallocation added to files
with that flag set?
Seems like a fair question, even if Swift's use of preallocation is
ill-advised.
I don't have all the speculative preallocation heuristics in my
head like you do Dave, but if I have it right, and it's i.e.:
1) preallocate 256k
2) inode gets XFS_DIFLAG_PREALLOC
3) write 257k
4) inode gets speculative preallocation added due to write past EOF
5) inode never gets preallocation trimmed due to XFS_DIFLAG_PREALLOC
that seems suboptimal.
Never doing speculative preallocation on files with XFS_DIFLAG_PREALLOC
set, regardless of file offset, would seem sane to me. App asked
to take control via prealloc; let it have it, and leave it at that.
(Of course now I'll go read the code to see if I understand it
properly...)
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-02-03 15:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 22:32 Request for information on bloated writes using Swift Dilip Simha
2016-02-03 2:47 ` Eric Sandeen
2016-02-03 3:40 ` Dilip Simha
2016-02-03 3:42 ` Dilip Simha
2016-02-03 6:37 ` Dave Chinner
2016-02-03 7:09 ` Dilip Simha
2016-02-03 8:30 ` Dave Chinner
2016-02-03 15:02 ` Eric Sandeen [this message]
2016-02-03 21:51 ` Dave Chinner
2016-02-03 22:43 ` Dilip Simha
2016-02-03 23:28 ` Dave Chinner
2016-02-04 6:16 ` Dilip Simha
2016-02-03 16:10 ` Dilip Simha
2016-02-03 16:15 ` Dilip Simha
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=56B21690.2070304@sandeen.net \
--to=sandeen@sandeen.net \
--cc=david@fromorbit.com \
--cc=nmdilipsimha@gmail.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