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 --]
next prev 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.