From: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Stray 4k extents with slow buffered writes
Date: Thu, 3 Mar 2016 13:28:29 +0100 [thread overview]
Message-ID: <56D82DED.5030107@googlemail.com> (raw)
Here's an observation that is not a bug (as in data corruption), just
somewhat odd and unnecessary behaviour. It could be considered a
performance or scalability bug.
I've noticed that slow slow buffered writes create a huge number of
unnecessary 4k sized extents. At first I wrote it off as odd buffering
behaviour of the application (a download manager), but it can be easily
reproduced. For example:
holger>wget --limit-rate=1m https://cdn.kernel.org/pub/linux/kernel/v4.x/testing/linux-4.5-rc6.tar.xz
(..downloads with 1 MB/s..)
holger>sync
holger>filefrag -ek linux-4.5-rc6.tar.xz
Filesystem type is: 9123683e
File size of linux-4.5-rc6.tar.xz is 88362576 (86292 blocks of 1024 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 14219: 230807476.. 230821695: 14220:
1: 14220.. 14223: 230838148.. 230838151: 4: 230821696:
2: 14224.. 29215: 230822324.. 230837315: 14992: 230838152:
3: 29216.. 44207: 230838152.. 230853143: 14992: 230837316:
4: 44208.. 44211: 230869576.. 230869579: 4: 230853144:
5: 44212.. 59199: 230853968.. 230868955: 14988: 230869580:
6: 59200.. 74191: 230869588.. 230884579: 14992: 230868956:
7: 74192.. 74195: 230898332.. 230898335: 4: 230884580:
8: 74196.. 86291: 230885620.. 230897715: 12096: 230898336: last,eof
linux-4.5-rc6.tar.xz: 9 extents found
Slower writes will generate even more extents; another ~200MB file
had >900 extents.
As expected defragment will collapse these stray extents with their
successors:
holger>btrfs filesystem defragment linux-4.5-rc6.tar.xz
holger>sync
holger>filefrag -ek linux-4.5-rc6.tar.xz
Filesystem type is: 9123683e
File size of linux-4.5-rc6.tar.xz is 88362576 (86292 blocks of 1024 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 14219: 230807476.. 230821695: 14220:
1: 14220.. 29215: 230922128.. 230937123: 14996: 230821696:
2: 29216.. 44207: 230838152.. 230853143: 14992: 230937124:
3: 44208.. 59199: 230937124.. 230952115: 14992: 230853144:
4: 59200.. 74191: 230869588.. 230884579: 14992: 230952116:
5: 74192.. 86291: 230952116.. 230964215: 12100: 230884580: last,eof
linux-4.5-rc6.tar.xz: 6 extents found
The obviously page-sized 4k extents happen to coincide with the 30s tx commit
(2 * ~15 MB at 1 MB/s). It looks like a benign race, as if the last dirty page
gets special treatment instead of being merged into wherever it should go.
That just seems wasteful to me.
Anyone got an idea?
-h
next reply other threads:[~2016-03-03 12:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 12:28 Holger Hoffstätte [this message]
2016-03-03 18:33 ` Stray 4k extents with slow buffered writes Liu Bo
2016-03-03 19:53 ` Holger Hoffstätte
2016-03-03 20:47 ` Austin S. Hemmelgarn
2016-03-03 21:50 ` Holger Hoffstätte
2016-03-03 22:13 ` Liu Bo
2016-03-04 1:37 ` Liu Bo
2016-03-04 12:17 ` Duncan
2016-03-03 20:55 ` Chris Mason
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=56D82DED.5030107@googlemail.com \
--to=holger.hoffstaette@googlemail.com \
--cc=linux-btrfs@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).