All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: xfs@oss.sgi.com
Subject: Re: Request for information on bloated writes using Swift
Date: Tue, 2 Feb 2016 20:47:24 -0600	[thread overview]
Message-ID: <56B16A3C.1030207@sandeen.net> (raw)
In-Reply-To: <CAFHL4X1JU02LFYntkqhYg1N++ZU46ML3v5higo1nRsPyoZxL5A@mail.gmail.com>



On 2/2/16 4:32 PM, Dilip Simha wrote:
> Hi,
> 
> I have a question regarding speculated preallocation in XFS, w.r.t
> kernel version: 3.16.0-46-generic. I am using Swift version: 1.0 and
> mkfs.xfs version 3.2.1
> 
> When I write a 256KiB file to Swift, I see that the underlying XFS
> uses 3x the amount of space/blocks to write that data. Upon
> performing detailed experiments, I see that when Swift uses fallocate
> (default approach), XFS doesn't reclaim the preallocated blocks that
> XFS allocated. Swift fallocate doesn't exceed the body size(256
> KiB).
> 
> Interestingly, when either allocsize=4k or when swift doesn't use
> fallocate, XFS doesn't consume additional space.
> 
> Can you please let me know if this is a known bug and if its fixed in
> the later versions?

Can you clarify the exact sequence of events?

i.e. -

xfs_io -f -c "fallocate 0 256k" -c "pwrite 0 256k" somefile

leads to unreaclaimed preallocation, while

xfs_io -f -c "pwrite 0 256k" somefile

does not?  Or is it some other sequence?  I don't have a
3.16 handy to test, but if you can describe it in more detail
that'd help.  Some of this is influenced by fs geometry, too
so xfs_info output would be good, along with any mount options
you might be using.

Are you preallocating with or without KEEP_SIZE?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-02-03  2:47 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 [this message]
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
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=56B16A3C.1030207@sandeen.net \
    --to=sandeen@sandeen.net \
    --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.