From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Vedran Vucic <vedran.vucic@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: illegal snapshot, cannot be deleted
Date: Thu, 12 Nov 2015 07:32:51 -0500 [thread overview]
Message-ID: <564486F3.5020804@gmail.com> (raw)
In-Reply-To: <CAHTEL3=r8kUJOU=xUAg2iG52HuWmqQ16QxUjY6d+zqbziW5+gw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]
On 2015-11-11 17:11, Vedran Vucic wrote:
> Hello,
>
> I use OpenSuse 13.2 on my Toshiba Satellite laptop. I noticed that I run
> out of disk space, checked documentation and I realized that there were
> many snapshots. I used Yast Snapper to delete snapshots.
> I noticed that one snapshot with number 748 could not be deleted.
> I entered terminal and after the command:
> snapper -c root delete 748
> I got message Illegal snapshot.
This sounds like some sort of issue with snapper, not BTRFS itself, but
see below for some suggestions.
> I woudl like to delete it since it is old one.
> Please find details about my system as requested on your wiki page.
> uname -a
> Linux linux-jjcc.site 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23 00:46:04
> UTC 2015 (6be6a97) i686 i686 i386 GNU/Linux
>
> btrfs --version
> btrfs-progs v4.0+20150429
>
> btrfs fi show
> Label: none uuid: d6934db3-3ac9-49d0-83db-287be7b995a5
> Total devices 1 FS bytes used 10.98GiB
> devid 1 size 18.71GiB used 18.71GiB path /dev/sda6
>
> btrfs fi df /
> Data, single: total=15.19GiB, used=10.37GiB
> System, DUP: total=8.00MiB, used=16.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, DUP: total=1.75GiB, used=622.53MiB
> Metadata, single: total=8.00MiB, used=0.00B
> GlobalReserve, single: total=208.00MiB, used=0.00B
> Please find attached dmesg.log as requested.
>
> Please advise what have to do in order to delete snapshot that is reported
> to be illegal.
Have you tried running 'btrfs subvolume delete' on the snapshot? You'll
have to find the full path to it first of course, but that shouldn't be
too hard. Based on the lack of BTRFS error messages in the kernel log
you posted, I'm pretty certain that this isn't an issue with the
filesystem itself (although the filesystem doesn't look particularly
healthy, see further below), so manually deleting the snapshot using the
regular BTRFS commands should work just fine. That said, you may also
want to look into changing the config for snapper, as it has a
ridiculously aggressive retention policy for snapshots by default, which
tends to lead to excessive space usage on filesystems smaller than about
250GB.
You may also want to look at running a balance on the filesystem, the
numbers from btrfs fi show and btrfs fi df look somewhat worrying,
you've got all the space on the disk allocated as chunks by BTRFS, but
have a significant amount of empty space in those chunks. Given that
fact, ENOSPC issues are a very real possibility, and you'll probably
have to run a series of partial balances to fix this (and it's important
to do it before it becomes a visible issue also, because once you start
getting ENOSPC errors, it is a lot harder to fix). Try running a
balance with '-dusage=0 -musage=0', then re-run repeatedly increasing
the number for both arguments by 5 each time until you get to 50. If a
run complains about 'ENOSPC errors during balance', re-run it with the
same number for -dusage and -musage. If you end up re-running with the
same value 3 times and keep getting the errors, then you're probably
beyond the point of this being fixable, and should just recreate the
filesystem (you do have backups, right?). Otherwise, after finishing
the run with '-dusage=50 -musage=50' successfully, run a full balance
without the dusage and musage options.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-11-12 12:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 22:11 illegal snapshot, cannot be deleted Vedran Vucic
2015-11-12 12:32 ` Austin S Hemmelgarn [this message]
2015-11-13 16:12 ` Vedran Vucic
2015-11-13 16:30 ` Austin S Hemmelgarn
2015-11-13 17:30 ` Vedran Vucic
2015-11-13 17:55 ` Henk Slager
2015-11-13 17:57 ` Vedran Vucic
2015-11-13 18:10 ` Austin S Hemmelgarn
2015-11-13 18:42 ` Hugo Mills
2015-11-13 19:40 ` Austin S Hemmelgarn
2015-11-13 19:55 ` Hugo Mills
2015-11-13 20:20 ` Austin S Hemmelgarn
2015-11-13 21:11 ` Duncan
2015-11-13 21:13 ` Hugo Mills
2015-11-13 23:53 ` Duncan
2015-11-13 20:15 ` Vedran Vucic
2015-11-13 20:18 ` Vedran Vucic
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=564486F3.5020804@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=vedran.vucic@gmail.com \
/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.