All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Hugo Mills <hugo@carfax.org.uk>,
	linux-btrfs.tebulin@xoxy.net, linux-btrfs@vger.kernel.org,
	David Sterba <dsterba@suse.cz>
Subject: Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
Date: Thu, 19 Nov 2015 15:18:19 -0500	[thread overview]
Message-ID: <564E2E8B.20900@gmail.com> (raw)
In-Reply-To: <20151119182850.GE24333@carfax.org.uk>

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

On 2015-11-19 13:28, Hugo Mills wrote:
> On Thu, Nov 19, 2015 at 06:35:24PM +0100, linux-btrfs.tebulin@xoxy.net wrote:
>> Will newer kernels do the balance on their own?
>
>     I think it's on the "projects" list on the wiki, so it may get done
> eventually. As I said above, I'm not aware of anyone working on it.
TBH, while it would be a nice feature, it's also something that has the 
potential to cause issues for people if it all happens at once.  IN many 
of the cases I've seen, the usual issue is lots of mostly empty data 
chunks (usually less than 20% in the two times I've run into this 
myself).  Based on this, having something in the kernel that could scan 
chunk usage every now and then, and repack mostly empty chunks if there 
is space already allocated in existing chunks, would probably 
significantly reduce the chances of this happening for most people, and 
cause much less noticeable performance degradation than triggering a 
full balance on a chunk allocation failure.  Since I started using a 
cron job to do a daily balance of chunks less than 20% full, and a 
weekly one for chunks less than 50% full, I've not run into these issues 
at all, and actually see on average better performance on my tradition 
hard disks.



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

  parent reply	other threads:[~2015-11-19 20:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 18:53 Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left? linux-btrfs.tebulin
2015-11-18 19:08 ` Hugo Mills
2015-11-19  0:42   ` Qu Wenruo
2015-11-19  2:16     ` Duncan
2015-11-20 11:39       ` Dmitry Katsubo
2015-11-20 13:21         ` Austin S Hemmelgarn
2015-11-20 13:27           ` Hugo Mills
2015-11-20 13:52             ` Austin S Hemmelgarn
2015-11-20 16:39               ` Dmitry Katsubo
2015-11-19 17:35   ` linux-btrfs.tebulin
2015-11-19 18:28     ` Hugo Mills
2015-11-19 18:45       ` linux-btrfs.tebulin
2015-11-19 18:56         ` linux-btrfs.tebulin
2015-11-19 19:26           ` linux-btrfs.tebulin
2015-11-20  3:14           ` Duncan
2015-11-20  9:38             ` linux-btrfs.tebulin
2015-11-20 10:44               ` Duncan
2015-11-20 14:25             ` Dmitry Katsubo
2015-11-19 20:18       ` Austin S Hemmelgarn [this message]
2015-11-19  5:58 ` Roman Mamedov
2015-11-19  8:31   ` Patrik Lundquist
2015-11-19 12:28 ` Austin S Hemmelgarn
2015-11-20  2:11   ` Duncan
2015-11-20 13:13     ` Austin S Hemmelgarn

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=564E2E8B.20900@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=dsterba@suse.cz \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs.tebulin@xoxy.net \
    --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 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.