All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Tovo Rabemanantsoa <tovo.rabemanantsoa@bordeaux.inra.fr>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Bad performance with near-full FS
Date: Mon, 15 Jun 2015 11:37:18 -0400	[thread overview]
Message-ID: <557EF12E.6000309@gmail.com> (raw)
In-Reply-To: <557EE4BF.2090908@bordeaux.inra.fr>

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

On 2015-06-15 10:44, Tovo Rabemanantsoa wrote:
> On 06/15/2015 03:29 PM, David Sterba wrote:
>> On Mon, Jun 15, 2015 at 02:47:24PM +0200, Tovo Rabemanantsoa wrote:
>>> Hi all,
>>> By browsing this list's archive, I've found a thread initiated by
>>> Charles Cazabon entitled: "Oddly slow read performance with near-full
>>> largish FS."
>>> Actually, I'm living the same experience but with a not so large FS
>>> (256GB on a SSD). Indeed, when I have less than 1GB of free space, the
>>> applications (thunderbird, thunar ...) on the machine become awfully
>>> slow but remain normal if I make some cleaning.
>>> Is it due to the FS or because it's an SSD hard disk ?
>>
>> 1G of 256G is less than a percent. At this level of usage you can expect
>> slowdown on any filesystem.
>>
>> This could be caused by free space fragmentation and even on a SSD, this
>> needs extra time to process.  Higher number of fragments needs more
>> structures to represent them and cost more CPU time, though this still
>> might not be the worst impact.
>>
>> AFAIK btrfs space handling logic needs to do more flushes of unwritten
>> data when the accounted free space goes below some threshold (because
>> COW needs to write the data twice before it switches to the new "root"
>> pointer and can free the previous version).
>
> Thanks for you reply,
> If I really understand, it's always a good idea to keep more than 1% of
> free space. Right ?
For almost any non-COW filesystem (ext4, XFS, JFS, etc.), 1% or 100MB 
(whichever is larger) is generally a good buffer.  On BTRFS, I would say 
at least 5% or 1.5G (again, whichever is larger; and if performance is a 
concern, go for at least 10-20%), as BTRFS is known to have some rather 
poor behavior when running very close to full.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

  parent reply	other threads:[~2015-06-15 15:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 12:47 Bad performance with near-full FS Tovo Rabemanantsoa
2015-06-15 13:29 ` David Sterba
2015-06-15 14:44   ` Tovo Rabemanantsoa
2015-06-15 15:36     ` Clemens Eisserer
2015-06-15 15:37     ` Austin S Hemmelgarn [this message]
2015-06-16  6:27       ` Tovo Rabemanantsoa

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=557EF12E.6000309@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tovo.rabemanantsoa@bordeaux.inra.fr \
    /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.