linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tobias <tracer@robotech.de>
To: nspmangalore@gmail.com
Cc: Chester <somethingsome2000@gmail.com>,
	"Fajar A. Nugraha" <list@fajar.net>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Extreme slowdown
Date: Fri, 16 Dec 2011 10:09:14 +0100	[thread overview]
Message-ID: <4EEB0ABA.5050202@robotech.de> (raw)
In-Reply-To: <4EEAC5D7.80707@gmail.com>

Am 16.12.2011 05:15, schrieb Shyam Prasad N:
> On 12/16/2011 09:14 AM, Chester wrote:
>> On Thu, Dec 15, 2011 at 8:19 PM, Fajar A. Nugraha<list@fajar.net>  
>> wrote:
>>> On Fri, Dec 16, 2011 at 1:49 AM, Tobias<tracer@robotech.de>  wrote:
>>>> Hi all!
>>>>
>>>> My BTRFS-FS ist getting really slow. Reading is ok, writing is slow 
>>>> and
>>>> deleting is horrible slow.
>>>>
>>>> There are many files and many links on the FS.
>>>>
>>>> # btrfs filesystem df /srv/storage
>>>> Data: total=3.09TB, used=3.07TB
>>> this is ... what, over 99% full?
>>> The slow down is normal, somewhat. Same thing happens on zfs, which
>>> became slower when usage is above 80-90%.
>> I don't think "total" actually means "total space available" it
>> increases as you use up more space.
Chester is right, the disk is a 8TB Array - the fs is less than half filled.

> Wouldn't it be more valuable to first collect enough info/data to 
> debug the problem, before suggesting ways to get out of this situation?
>
> AFAIK, the slowness could be due to several reasons:
> 1. Slow disk writes.
That depends on what is slow for you. Its a SATA-Disc-Array so good 
linear Read/Write and low IOPs (compared to SSDs or SAS-Discs)

> 2. Too many things to commit to the disk.
I think there should be very little data to write/commit when deleting 
files. Remember: writing is slow, but acceptable - deleting is the problem

> 3. Too many things to do to actually accomplish the writes.
I just do rm -rf xxx. What has BTRFS to do to actually delete a file or 
directory?

> Is there some sort of profiling which we can enable, which can give us 
> info about the speeds and quantities of read and write traffic on the fs?
> Aren't there btrfs statistics that we can print out, which can give us 
> these info? If not, we probably should think about adding some.

Good question - maybe a dev can say?

Tobias


  reply	other threads:[~2011-12-16  9:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 18:49 Extreme slowdown Tobias
2011-12-16  2:09 ` Liu Bo
2011-12-16  8:51   ` Tobias
2011-12-16  9:11     ` Hugo Mills
2011-12-16  2:19 ` Fajar A. Nugraha
2011-12-16  3:44   ` Chester
2011-12-16  4:15     ` Shyam Prasad N
2011-12-16  9:09       ` Tobias [this message]
2011-12-16  9:19         ` Sander
2011-12-16 17:45           ` Tobias

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=4EEB0ABA.5050202@robotech.de \
    --to=tracer@robotech.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=list@fajar.net \
    --cc=nspmangalore@gmail.com \
    --cc=somethingsome2000@gmail.com \
    /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).