linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "cheater00 ." <cheater00@gmail.com>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Bad fs performance, IO freezes
Date: Mon, 26 Oct 2015 18:43:08 +0100	[thread overview]
Message-ID: <CA+9GZUipGeuNuVP2=g2+gbWpJWxbeHVQEcQ5QYfOCWjkv5JDcQ@mail.gmail.com> (raw)
In-Reply-To: <CA+9GZUi9jiJ9RBezrh7Xi4_1eBpyeNBdrs+hYxsECaa_a9_csA@mail.gmail.com>

So far I cannot reproduce. If I don't post again this means the issue
has been fixed by updating the kernel.

On Mon, Oct 26, 2015 at 4:40 PM, cheater00 . <cheater00@gmail.com> wrote:
> I have located 4.3.0-rc7 binaries which I will now try.
>
> On Mon, Oct 26, 2015 at 3:38 PM, cheater00 . <cheater00@gmail.com> wrote:
>> Thanks for the reply. What version did this go into? I'll try getting
>> a prebuilt backport of the kernel, building source could slow things
>> down considerably, but debs will not be available for the latest few
>> minor versions I guess. So if you can tell me a min version, I'll try
>> to find the latest deb newer than that, or I'll build if that's not
>> available.
>>
>> On Mon, Oct 26, 2015 at 3:25 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
>>> On 10/26/2015 08:16 PM, cheater00 . wrote:
>>>>
>>>> Hi guys,
>>>> I am running into really bad performance. Here's my setup:
>>>>
>>>> WD Red 6 TB connected over USB2 to my core i7 laptop, running Ubuntu
>>>> 32-bit with kernel 4.0.4-040004-generic #201505171336.
>>>>
>>>> Single btrfs partition covering whole disk.
>>>>
>>>> Autodefrag is on.
>>>>
>>>> fstab line:
>>>> UUID=... /media/X btrfs rw,nosuid,nodev,autodefrag 0 0
>>>>
>>>> Sometimes when files are being modified or removed, I see
>>>> btrfs-transacti eat 100% cpu; during this time no io operations
>>>> succeed, that is, they're all stalled. You can't even ls on that fs.
>>>> This happens for several minutes then normal operation resumes. There
>>>> doesn't seem to be a rule to what will trigger this, other than
>>>> opening a single file and reading usually works quite well. (say,
>>>> watching a movie while all other programs are closed). But even moving
>>>> files off the disks triggers some sort of bug. Just now I am moving a
>>>> few files (just 30gb worth) onto another disk, and the bug triggers.
>>>> So btrfs-transacti was eating my cpu for over 5 minutes and according
>>>> to mv's output after this was done and cpu usage went back to normal
>>>> what I was waiting for was for a tiny png file to be removed. This is
>>>> pretty bad.
>>>>
>>>> I have tried defragmenting directories where files are being accessed
>>>> and moved. This hasn't helped.
>>>>
>>>> This happens whether the FS is near full or not. It currently is near
>>>> full but it wasn't before and it still did that. It still has about ~
>>>> 100GB free space now.
>>>>
>>>> The more things are happening the more often this bug gets triggered.
>>>> So if I have utorrent running and its temporary downloads directory is
>>>> there, its download speed graph will be a few spikes of running at
>>>> several MB/sec separated by durations of 0 download speed.
>>>>
>>>> Nothing seems to show up in dmesg or syslog.
>>>>
>>>> I have asked in #btrfs but the suggestions ended up not fixing the
>>>> issue (autodefrag, defrag dirs).
>>>>
>>>> Please advise what I should do with this issue.
>>>
>>>
>>> It might be related to delayed ref rework, the last time I saw this kind of
>>> hanging problem about btrfs-transaction eating cpu is that because btrfs
>>> doesn't merge delayed refs, it'd be best to try the lastest kernel and if
>>> the issue is not resolved, then we can work out a reproducer and provide
>>> debugging.
>>>
>>> Thanks,
>>>
>>> Liubo

  reply	other threads:[~2015-10-26 17:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-26 12:16 Bad fs performance, IO freezes cheater00 .
2015-10-26 13:32 ` Donald Pearson
2015-10-26 13:36   ` cheater00 .
2015-10-26 13:45     ` Donald Pearson
2015-10-26 13:46       ` cheater00 .
2015-10-26 13:56         ` cheater00 .
2015-10-26 14:00           ` Donald Pearson
2015-10-26 14:25 ` Liu Bo
2015-10-26 14:38   ` cheater00 .
2015-10-26 15:40     ` cheater00 .
2015-10-26 17:43       ` cheater00 . [this message]
2015-10-26 18:31         ` cheater00 .
2015-10-27  2:00           ` cheater00 .
2015-10-27  6:39             ` Duncan
2015-10-27  8:55               ` cheater00 .
2015-10-27 11:44             ` Austin S Hemmelgarn
2015-10-27 13:00               ` Henk Slager
2015-10-27 13:30                 ` Austin S Hemmelgarn
2015-10-27 14:22                   ` cheater00 .
2015-10-27 14:26                     ` cheater00 .
2015-10-27 14:30                       ` cheater00 .
2015-10-27 14:43                         ` cheater00 .
2015-10-27 15:01                           ` Holger Hoffstätte
2015-10-27 15:05                             ` cheater00 .
2015-10-27 15:07                               ` cheater00 .
2015-10-27 15:22                                 ` Holger Hoffstätte
2015-10-27 15:26                           ` Austin S Hemmelgarn
2015-10-29 13:03                             ` cheater00 .
2015-10-29 14:00                               ` Austin S Hemmelgarn
2015-10-29 15:49                                 ` cheater00 .
2015-10-29 18:49                                   ` Henk Slager
2015-10-29 20:01                                   ` Austin S Hemmelgarn
2015-11-06 13:37                                     ` cheater00 .

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='CA+9GZUipGeuNuVP2=g2+gbWpJWxbeHVQEcQ5QYfOCWjkv5JDcQ@mail.gmail.com' \
    --to=cheater00@gmail.com \
    --cc=bo.li.liu@oracle.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).