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 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.