From: Charles Cazabon <charlesc-lists-btrfs@pyropus.ca>
To: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Oddly slow read performance with near-full largish FS
Date: Fri, 19 Dec 2014 10:58:49 -0600 [thread overview]
Message-ID: <20141219165849.GA15104@pyropus.ca> (raw)
In-Reply-To: <5493E8B0.1080107@jp.fujitsu.com>
Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> wrote:
>
> Let me ask some questions.
Sure - thanks for taking an interest.
> On 2014/12/17 11:42, Charles Cazabon wrote:
> > There's roughly 16TB of data in this filesystem (the filesystem is ~17TB).
> > The btrfs filesystem is a simple single volume, no snapshots, multiple
> > devices, or anything like that. It's an LVM logical volume on top of
> > dmcrypt on top of an mdadm RAID set (8 disks in RAID 6).
>
> Q1. You mean your Btrfs file system exists on the top of
> the following deep layers?
>
> +---------------+
> |Btrfs(single) |
> +---------------+
> |LVM(non RAID?) |
> +---------------+
> |dmcrypt |
> +---------------+
> |mdadm RAID set |
> +---------------+
Yes, precisely. mdadm is used to make a large RAID6 device, which is
encrypted with LUKS, on top of which is layered LVM (for ease of management),
and the btrfs filesystem sits on that.
> Q2. If Q1 is true, is it possible to reduce that layers as follows?
>
> +-----------+
> |Btrfs(*1) |
> +-----------+
> |dmcrypt |
> +-----------+
I don't see how I could do that - I simply have far too much data for a single
disk (not to mention I don't want to risk loss of data from a single disk
failing). This filesystem has 16.x TB of data in it at present.
> It's because there are too many layers and these have
> the same/similar features and heavy layered file system
> tends to cause more trouble than thinner layered ones
> regardless of file system type.
This configuration is one I've been using for many years. It's only recently
that I've noticed it being particularly slow with btrfs -- I don't know if
that's because the filesystem has filled up past some critical point, or due
to something else entirely. That's why I'm trying to figure this out.
> *1) Currently I don't recommend you to use RAID56 of Btrfs.
> So, if RAID6 is mandatory, mdadm RAID6 is also necessary.
Yes, exactly. That's why I use mdadm.
> > The speeds I'm seeing (with iotop) fluctuate a lot. They spend most of
> > the time in the range of 1-3 MB/s, with large periods of time where no IO
> > seems to happen at all, and occasional short spikes to ~25-30 MB/s.
> > System load seems to sit around 10-12 (with only 2 processes reported as
> > running, everything else sleeping) while this happens.
[...]
> > Other filesystems on the same physical disks have no trouble exceeding
> > 100MB/s reads. The machine is not swapping (16GB RAM, ~8GB swap with 0
> > swap used).
>
> Q3. They are also consist of the following layers?
Yes, exactly the same configuration. The fact that I don't see any speed
problems with other filesystems (even in the same LVM volume group) leads me
in the direction of suspecting something to do with btrfs.
> Q4. Are other filesystems also near-full?
No, not particularly. Now, the btrfs volume in question isn't exactly close
to full - there's more than 500 GB free. It's just *relatively* full.
> Q5. Is there any error/warning message about
> Btrfs/LVM/dmcrypt/mdadm/hardwares?
No, no errors or warnings in logs related to the disks, LVM, or btrfs. I have
historically, with previous kernels, gotten the "task blocked for more than
120 seconds" warnings fairly often, but I haven't seen those lately.
Is there any other info I can collect on this that would help?
Thanks,
Charles
--
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
-----------------------------------------------------------------------
next prev parent reply other threads:[~2014-12-19 16:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 2:42 Oddly slow read performance with near-full largish FS Charles Cazabon
2014-12-19 8:58 ` Satoru Takeuchi
2014-12-19 16:58 ` Charles Cazabon [this message]
2014-12-19 17:33 ` Duncan
2014-12-20 8:53 ` Chris Murphy
2014-12-20 10:03 ` Robert White
2014-12-20 10:57 ` Robert White
2014-12-21 16:32 ` Charles Cazabon
2014-12-21 21:32 ` Robert White
2014-12-21 22:53 ` Charles Cazabon
2014-12-22 0:38 ` Robert White
2014-12-25 3:14 ` Charles Cazabon
2014-12-22 14:16 ` Austin S Hemmelgarn
2014-12-25 3:15 ` Charles Cazabon
2014-12-22 2:13 ` Satoru Takeuchi
2014-12-25 3:18 ` Charles Cazabon
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=20141219165849.GA15104@pyropus.ca \
--to=charlesc-lists-btrfs@pyropus.ca \
--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).