From: Dave Chinner <david@fromorbit.com>
To: Gionatan Danti <g.danti@assyoma.it>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Slow file stat/deletion
Date: Tue, 29 Nov 2016 08:53:08 +1100 [thread overview]
Message-ID: <20161128215308.GD28177@dastard> (raw)
In-Reply-To: <a5774248-db44-bdfe-2310-bb1a327756fb@assyoma.it>
On Mon, Nov 28, 2016 at 10:51:42AM +0100, Gionatan Danti wrote:
>
>
> On 27/11/2016 23:14, Dave Chinner wrote:
> >
> >Ah, hard link farms. aka "How to fragment the AGI btrees for fun and
> >profit."
> >
>
> Interesting... there is anything I can read about AGI fragmentation?
Read up on finobt and the bug reports on the list about how inode
allocation slows to a crawl....
> >Nope, but it means that what should be sequential IO is probably
> >going to be random. i.e. instead of directory/inode/extent reading
> >IO having minimum track-track seek latency because they are all
> >nearby (1-2ms), they'll be average seeks (6-7ms) because locality is no
> >longer as the filesystem has optimised for.
> >
>
> Should not thinp overhead be minimized by the big (8 MB) chunk size?
Minimised - maybe. Removed - no.
> Are inode allocation so much scattered around LBAs?
Yes. XFS distributes inodes across the entire device LBA.
> Maybe the
> slowdown can be increased by bad journal placement (I imagine it is
> near the start of the disk, while current read/write activity surely
> happen near the end)?
Contributing factor, yes. You just have to live with that thinp
behaviour.
> >noalign affects data placement only, and only for filesystems that
> >have a stripe unit/width set, which yours doesn't:
> >
> >> sunit=0 swidth=0 blks
>
> Isn't that the proper results of "noalign"?
No. "noalign" is a mount option - the sunit/swidth are geometry
values stored in the superblock. noalign will override the
superblock values, but it does not make them go away.
> By opting for "noalign"
> I am telling mkfs to discard any stripe information, right?
No. You are telling it to ignore stripe alignment for file data
allocation purposes.
> >Yes. Made worse by being on a thinp volume.
>
> I can't do anything for that?
Nope. There's always going to be a penalty for subverting the
filesystem's physical layout optimisations on storage subsystems
that require physical layout optimisation for performance.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-11-28 21:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 10:40 Slow file stat/deletion Gionatan Danti
2016-11-27 22:14 ` Dave Chinner
2016-11-28 9:51 ` Gionatan Danti
2016-11-28 21:53 ` Dave Chinner [this message]
2016-11-29 7:53 ` Gionatan Danti
2017-04-28 20:14 ` Gionatan Danti
2017-04-28 21:03 ` Eric Sandeen
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=20161128215308.GD28177@dastard \
--to=david@fromorbit.com \
--cc=g.danti@assyoma.it \
--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).