linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Simon King <simon.king@uni-koeln.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: How to delete this snapshot, and how to succeed with balancing?
Date: Sat, 31 Oct 2015 18:33:37 +0000	[thread overview]
Message-ID: <20151031183337.GG21103@carfax.org.uk> (raw)
In-Reply-To: <5634FB01.9030602@uni-koeln.de>

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

On Sat, Oct 31, 2015 at 06:31:45PM +0100, Simon King wrote:
> Hi Hugo,
> 
> Am 31.10.2015 um 17:41 schrieb Hugo Mills:
> >> linux-va3e:~ # uname -a
> >> Linux linux-va3e.site 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23
> >> 00:46:04 UTC 2015 (6be6a97) x86_64 x86_64 x86_64 GNU/Linux
> > 
> >    OK, that's a bit old -- you would probably do well to upgrade this
> > anyway, regardless of the issues you're having. (I'd recommend 4.1 at
> > the moment; there's a bug in 4.2 at the moment that affects
> > balancing).
> 
> The latest version of openSuse is Tumbleweed, in a few days there will
> be openSuse Leap; I am not sure what kernel it would give me.
> 
> >    I thought snapper could automatically delete old snapshots. (I've
> > never used it, though, so I'm not sure). Worth looking at the snapper
> > config to see if you can tell it how many to keep.
> 
> Probably it can, right.
> 
> >    You're telling it to move the first two chunks with less than 10%
> > usage. If all the other chunks are full, and there are two chunks (one
> > data, one metadata) with less than 10% usage, then they'll be moved to
> > two new chunks... with less than 10% usage. So it's perfectly possible
> > that the same command will show the same output.
> 
> Do I understand correctly: In that situation, balancing would have no
> benefit, as two old chunks are moved to two new chunks? Then why are
> they moved at all?

   Because that's what balance does -- it's a fairly blunt tool for
one thing (evening out the usage across multiple devices) that happens
to have some useful side-effects (compacting space usage into smaller
numbers of block groups and freeing up the empty ones).

> >    Incidentally, I would suggest using -dlimit=2 on its own, rather
> > than both limit and usage.
> 
> I combined the two, since -dlimit on its own won't work:
> 
> linux-va3e:~ # btrfs balance start -dlimit=2 /
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail

   And this is with a filesystem that's not fully allocated?
(i.e. btrfs fi show indicates that used and total are different for
each device). If that's the case, then you may have hit a known but
unfixed bug to do with space allocation.

> >    "btrfs balance start /" should rebalance the whole filesystem --
> 
> linux-va3e:~ # btrfs balance start /
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail
> linux-va3e:~ # dmesg | tail
> [ 9814.499013] BTRFS info (device sda2): found 8153 extents
> [ 9815.254270] BTRFS info (device sda2): relocating block group
> 820062978048 flags 36
> [ 9826.335122] BTRFS info (device sda2): found 8182 extents
> [ 9826.858482] BTRFS info (device sda2): relocating block group
> 805064146944 flags 36
> [ 9839.444820] BTRFS info (device sda2): found 8184 extents
> [ 9839.822108] BTRFS info (device sda2): relocating block group
> 794595164160 flags 36
> [ 9850.456697] BTRFS info (device sda2): found 8143 extents
> [ 9850.778264] BTRFS info (device sda2): relocating block group
> 794460946432 flags 36
> [ 9862.546336] BTRFS info (device sda2): found 8140 extents
> [ 9862.890330] BTRFS info (device sda2): 12 enospc errors during balance
> 
> 
> > not that you'd need to for purposes of dealing with space usage
> > issues.
> 
> I know that "df" is different from "btrfs fi df". However, I see that df
> shows significantly more free space after balancing. Also, when my
> computer became unusable, the problem disappeared by balancing and
> defragmentation (deleting the old snapshots was not enough).
> 
> Unfortunately, df also shows significantly less free space after
> UNSUCCESSFUL balancing.
> 
> >    You may have more success using mkfs.btrfs --mixed when you create
> > the FS, which puts data and metadata in the same chunks.
> 
> Can I do this in the running system? Or would that only be an option
> during upgrade of openSuse Harlequin to Tumbleweed/Leap? Or even worse:
> Only an option after nuking the old installation and installing a new
> one from scratch?

   You'd have to recreate the FS, so it's a matter of a reinstall, or
nuking it and restoring from your backups.

   Hugo.

-- 
Hugo Mills             | Le Corbusier's plan for improving Paris involved the
hugo@... carfax.org.uk | assassination of the city, and its rebirth as tower
http://carfax.org.uk/  | blocks.
PGP: E2AB1DE4          |                   Robert Hughes, The Shock of the New

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2015-10-31 18:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-31 15:26 How to delete this snapshot, and how to succeed with balancing? Simon King
2015-10-31 16:41 ` Hugo Mills
2015-10-31 17:31   ` Simon King
2015-10-31 18:33     ` Hugo Mills [this message]
2015-10-31 20:56       ` Simon King
2015-10-31 22:45         ` Henk Slager
2015-10-31 22:51           ` Hugo Mills
2015-11-01  3:05     ` Duncan

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=20151031183337.GG21103@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=simon.king@uni-koeln.de \
    /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).