From: Dilip Simha <nmdilipsimha@gmail.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: Request for information on bloated writes using Swift
Date: Tue, 2 Feb 2016 19:40:34 -0800 [thread overview]
Message-ID: <CAFHL4X0QBtFpz3=HMVMrp6NoaW5BRkDSoTE1yJQvQ=0JrW5+YQ@mail.gmail.com> (raw)
In-Reply-To: <56B16A3C.1030207@sandeen.net>
[-- Attachment #1.1: Type: text/plain, Size: 3230 bytes --]
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
# xfs_io -f -c "pwrite 0 257k" /srv/node/r1/t2.txt
# stat /srv/node/r1/t2.txt | grep Blocks
Size: 263168 *Blocks*: 520 IO Block: 4096 regular file
# xfs_info /srv/node/r1
meta-data=/dev/mapper/35000cca05831283c-part2 isize=256 agcount=4,
agsize=183141504 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=732566016, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=357698, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# cat /proc/mounts | grep r1
/dev/mapper/35000cca05831283c-part2 /srv/node/*r1* xfs
rw,nosuid,nodev,noexec,noatime,nodiratime,attr2,inode64,logbufs=8,noquota 0
0
I waited for around 15 mins before collecting the stat output to give the
background reclamation logic a fair chance to do its job. I also tried
changing the value of speculative_prealloc_lifetime from 300 to 10. But it
was of no use.
cat /proc/sys/fs/xfs/speculative_prealloc_lifetime
10
Regards,
Dilip
On Tue, Feb 2, 2016 at 6:47 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>
>
> 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
>
[-- Attachment #1.2: Type: text/html, Size: 4785 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-02-03 3:41 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 [this message]
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='CAFHL4X0QBtFpz3=HMVMrp6NoaW5BRkDSoTE1yJQvQ=0JrW5+YQ@mail.gmail.com' \
--to=nmdilipsimha@gmail.com \
--cc=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.