public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* Bad performance with near-full FS
@ 2015-06-15 12:47 Tovo Rabemanantsoa
  2015-06-15 13:29 ` David Sterba
  0 siblings, 1 reply; 6+ messages in thread
From: Tovo Rabemanantsoa @ 2015-06-15 12:47 UTC (permalink / raw)
  To: Btrfs BTRFS

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 ?
Thanks in advance

-- 
Tovo J. Rabemanantsoa
IT Manager
Quality correspondent
INRA - UMR ISPA [Interactions Sol Plante Atmosphère]
Villenave d'Ornon - Gironde, France
+33 5 57 12 24 09

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad performance with near-full FS
  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
  0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2015-06-15 13:29 UTC (permalink / raw)
  To: Tovo Rabemanantsoa; +Cc: Btrfs BTRFS

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad performance with near-full FS
  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
  0 siblings, 2 replies; 6+ messages in thread
From: Tovo Rabemanantsoa @ 2015-06-15 14:44 UTC (permalink / raw)
  To: Btrfs BTRFS

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 ?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad performance with near-full FS
  2015-06-15 14:44   ` Tovo Rabemanantsoa
@ 2015-06-15 15:36     ` Clemens Eisserer
  2015-06-15 15:37     ` Austin S Hemmelgarn
  1 sibling, 0 replies; 6+ messages in thread
From: Clemens Eisserer @ 2015-06-15 15:36 UTC (permalink / raw)
  To: Tovo Rabemanantsoa, linux-btrfs

Hi,


> Thanks for you reply,
> If I really understand, it's always a good idea to keep more than 1% of
> free space. Right ?

Usually the rule of thumb is 10-20%.

Br, Clemens

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad performance with near-full FS
  2015-06-15 14:44   ` Tovo Rabemanantsoa
  2015-06-15 15:36     ` Clemens Eisserer
@ 2015-06-15 15:37     ` Austin S Hemmelgarn
  2015-06-16  6:27       ` Tovo Rabemanantsoa
  1 sibling, 1 reply; 6+ messages in thread
From: Austin S Hemmelgarn @ 2015-06-15 15:37 UTC (permalink / raw)
  To: Tovo Rabemanantsoa, Btrfs BTRFS

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad performance with near-full FS
  2015-06-15 15:37     ` Austin S Hemmelgarn
@ 2015-06-16  6:27       ` Tovo Rabemanantsoa
  0 siblings, 0 replies; 6+ messages in thread
From: Tovo Rabemanantsoa @ 2015-06-16  6:27 UTC (permalink / raw)
  To: Btrfs BTRFS

On 06/15/2015 05:37 PM, Austin S Hemmelgarn wrote:

> 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.
> 
> 
I got it.
Thanks all !

T.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-06-16  6:27 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2015-06-16  6:27       ` Tovo Rabemanantsoa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox