Re: illegal snapshot, cannot be deleted

2015-11-13 Thread Vedran Vucic
Hello,

I succeeded to delete illegal snapshot with command:
btrfs subvolume delete /.snapshots/741/snapshot
When I have done
btrfs balance / -dusage=0 -musage=0
increasing value up to 4o I did not have issues.
But on value 4- for-dusage= and -musage=
I got message that there is no space left on disk.
Do you have any advice how to manage that?

Vedran


On Thu, Nov 12, 2015 at 1:32 PM, Austin S Hemmelgarn
<ahferro...@gmail.com> wrote:
> 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
>>  devid1 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.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: illegal snapshot, cannot be deleted

2015-11-13 Thread Vedran Vucic
Hello,

Here are outputs of commands as you requested:
 btrfs fi df /
Data, single: total=8.00GiB, used=7.71GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.12GiB, used=377.25MiB
GlobalReserve, single: total=128.00MiB, used=0.00B

btrfs fi show
Label: none  uuid: d6934db3-3ac9-49d0-83db-287be7b995a5
Total devices 1 FS bytes used 8.08GiB
devid1 size 18.71GiB used 10.31GiB path /dev/sda6

btrfs-progs v4.0+20150429

Thanks,

vedran

On Fri, Nov 13, 2015 at 5:30 PM, Austin S Hemmelgarn
<ahferro...@gmail.com> wrote:
> On 2015-11-13 11:12, Vedran Vucic wrote:
>>
>> Hello,
>>
>> I succeeded to delete illegal snapshot with command:
>> btrfs subvolume delete /.snapshots/741/snapshot
>> When I have done
>> btrfs balance / -dusage=0 -musage=0
>> increasing value up to 4o I did not have issues.
>> But on value 4- for-dusage= and -musage=
>> I got message that there is no space left on disk.
>> Do you have any advice how to manage that?
>
>
> Can you post the output of 'btrfs fi df' and 'btrfs fi show' again? Both
> should have changed after the balance, and I'd need to see what it looks
> like now to be able to give any reasonable advice.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: illegal snapshot, cannot be deleted

2015-11-13 Thread Vedran Vucic
Hello,

My system is on laptop that is not heavy duty such as servers.
openSuse 13.2 was installed approx 2 months ago so the issue did not
appear due to longterm lack of administration or maintenance.
Please let me know if I can help in any other way.

Thanks,

vedran

On Fri, Nov 13, 2015 at 9:15 PM, Vedran Vucic <vedran.vu...@gmail.com> wrote:
> Hello,
>
> I guess that it might be bug in kernel.
> I was successful this:
> btrfs balance start / -dusage=50 -musage=35
>
> musage above 35 caused ENOSPC message. Otherwise it was good.
> Thanks on support,
>
> vedran
>
> On Fri, Nov 13, 2015 at 7:42 PM, Hugo Mills <h...@carfax.org.uk> wrote:
>> On Fri, Nov 13, 2015 at 01:10:12PM -0500, Austin S Hemmelgarn wrote:
>>> On 2015-11-13 12:30, Vedran Vucic wrote:
>>> >Hello,
>>> >
>>> >Here are outputs of commands as you requested:
>>> >  btrfs fi df /
>>> >Data, single: total=8.00GiB, used=7.71GiB
>>> >System, DUP: total=32.00MiB, used=16.00KiB
>>> >Metadata, DUP: total=1.12GiB, used=377.25MiB
>>> >GlobalReserve, single: total=128.00MiB, used=0.00B
>>> >
>>> >btrfs fi show
>>> >Label: none  uuid: d6934db3-3ac9-49d0-83db-287be7b995a5
>>> > Total devices 1 FS bytes used 8.08GiB
>>> > devid1 size 18.71GiB used 10.31GiB path /dev/sda6
>>> >
>>> >btrfs-progs v4.0+20150429
>>> >
>>> Hmm, that's odd, based on these numbers, you should be having no
>>> issue at all trying to run a balance. You might be hitting some
>>> other bug in the kernel, however, but I don't remember if there were
>>> any known bugs related to ENOSPC or balance in the version you're
>>> running.
>>
>>There's one specific bug that shows up with ENOSPC exactly like
>> this. It's in all versions of the kernel, there's no known solution,
>> and no guaranteed mitigation strategy, I'm afraid. Various things like
>> balancing, or adding, balancing, and removing a device again have been
>> tried. Sometimes they seem to help; sometimes they just make the
>> problem worse.
>>
>>We average maybe one report a week or so(*) with this particular
>> set of symptoms.
>>
>>Hugo.
>>
>> (*) 
>>
>>>  You might see if trying to re-run the balance with
>>> '-dusage=40 -musage=40' works correctly (I've seen cases where the
>>> first run fails, but subsequent ones work because the first one made
>>> some progress despite failing).
>>> >On Fri, Nov 13, 2015 at 5:30 PM, Austin S Hemmelgarn
>>> ><ahferro...@gmail.com> wrote:
>>> >>On 2015-11-13 11:12, Vedran Vucic wrote:
>>> >>>
>>> >>>Hello,
>>> >>>
>>> >>>I succeeded to delete illegal snapshot with command:
>>> >>>btrfs subvolume delete /.snapshots/741/snapshot
>>> >>>When I have done
>>> >>>btrfs balance / -dusage=0 -musage=0
>>> >>>increasing value up to 4o I did not have issues.
>>> >>>But on value 4- for-dusage= and -musage=
>>> >>>I got message that there is no space left on disk.
>>> >>>Do you have any advice how to manage that?
>>> >>
>>> >>
>>> >>Can you post the output of 'btrfs fi df' and 'btrfs fi show' again? Both
>>> >>should have changed after the balance, and I'd need to see what it looks
>>> >>like now to be able to give any reasonable advice.
>>> >>
>>> >>
>>>
>>>
>>
>>
>>
>> --
>> Hugo Mills | You can play with your friends' privates, but you
>> hugo@... carfax.org.uk | can't play with your friends' childrens' privates.
>> http://carfax.org.uk/  |
>> PGP: E2AB1DE4  |   C++ coding 
>> rule
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: illegal snapshot, cannot be deleted

2015-11-13 Thread Vedran Vucic
Hello,

I guess that it might be bug in kernel.
I was successful this:
btrfs balance start / -dusage=50 -musage=35

musage above 35 caused ENOSPC message. Otherwise it was good.
Thanks on support,

vedran

On Fri, Nov 13, 2015 at 7:42 PM, Hugo Mills <h...@carfax.org.uk> wrote:
> On Fri, Nov 13, 2015 at 01:10:12PM -0500, Austin S Hemmelgarn wrote:
>> On 2015-11-13 12:30, Vedran Vucic wrote:
>> >Hello,
>> >
>> >Here are outputs of commands as you requested:
>> >  btrfs fi df /
>> >Data, single: total=8.00GiB, used=7.71GiB
>> >System, DUP: total=32.00MiB, used=16.00KiB
>> >Metadata, DUP: total=1.12GiB, used=377.25MiB
>> >GlobalReserve, single: total=128.00MiB, used=0.00B
>> >
>> >btrfs fi show
>> >Label: none  uuid: d6934db3-3ac9-49d0-83db-287be7b995a5
>> > Total devices 1 FS bytes used 8.08GiB
>> > devid1 size 18.71GiB used 10.31GiB path /dev/sda6
>> >
>> >btrfs-progs v4.0+20150429
>> >
>> Hmm, that's odd, based on these numbers, you should be having no
>> issue at all trying to run a balance. You might be hitting some
>> other bug in the kernel, however, but I don't remember if there were
>> any known bugs related to ENOSPC or balance in the version you're
>> running.
>
>There's one specific bug that shows up with ENOSPC exactly like
> this. It's in all versions of the kernel, there's no known solution,
> and no guaranteed mitigation strategy, I'm afraid. Various things like
> balancing, or adding, balancing, and removing a device again have been
> tried. Sometimes they seem to help; sometimes they just make the
> problem worse.
>
>We average maybe one report a week or so(*) with this particular
> set of symptoms.
>
>Hugo.
>
> (*) 
>
>>  You might see if trying to re-run the balance with
>> '-dusage=40 -musage=40' works correctly (I've seen cases where the
>> first run fails, but subsequent ones work because the first one made
>> some progress despite failing).
>> >On Fri, Nov 13, 2015 at 5:30 PM, Austin S Hemmelgarn
>> ><ahferro...@gmail.com> wrote:
>> >>On 2015-11-13 11:12, Vedran Vucic wrote:
>> >>>
>> >>>Hello,
>> >>>
>> >>>I succeeded to delete illegal snapshot with command:
>> >>>btrfs subvolume delete /.snapshots/741/snapshot
>> >>>When I have done
>> >>>btrfs balance / -dusage=0 -musage=0
>> >>>increasing value up to 4o I did not have issues.
>> >>>But on value 4- for-dusage= and -musage=
>> >>>I got message that there is no space left on disk.
>> >>>Do you have any advice how to manage that?
>> >>
>> >>
>> >>Can you post the output of 'btrfs fi df' and 'btrfs fi show' again? Both
>> >>should have changed after the balance, and I'd need to see what it looks
>> >>like now to be able to give any reasonable advice.
>> >>
>> >>
>>
>>
>
>
>
> --
> Hugo Mills | You can play with your friends' privates, but you
> hugo@... carfax.org.uk | can't play with your friends' childrens' privates.
> http://carfax.org.uk/  |
> PGP: E2AB1DE4  |   C++ coding rule
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


illegal snapshot, cannot be deleted

2015-11-11 Thread Vedran Vucic
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.
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
devid1 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.
Thanks
Vedran Vucic
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.7-29-desktop (geeko@buildhost) (gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP PREEMPT Fri Oct 23 00:46:04 UTC 2015 (6be6a97)
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x5fe6] usable
[0.00] BIOS-e820: [mem 0x5fe7-0x5fef] ACPI NVS
[0.00] BIOS-e820: [mem 0x5ff0-0x5fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: TOSHIBA Satellite A200/CAPELL VALLEY(NAPA) CRB, BIOS 1.2003/24/2007
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x5fe70 max_arch_pfn = 0x100
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask FC000 write-back
[0.00]   1 base 04000 mask FE000 write-back
[0.00]   2 base 05FF0 mask 0 uncachable
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000f71d0-0x000f71df] mapped at [c00f71d0]
[0.00] Scanning 1 areas for low memory corruption
[0.00] initial memory mapped: [mem 0x-0x011f]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x36a0-0x36bf]
[0.00]  [mem 0x36a0-0x36bf] page 2M
[0.00] init_memory_mapping: [mem 0x3400-0x369f]
[0.00]  [mem 0x3400-0x369f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x33ff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x33ff] page 2M
[0.00] init_memory_mapping: [mem 0x36c0-0x36dfdfff]
[0.00]  [mem 0x36c0-0x36dfdfff] page 4k
[0.00] BRK [0x00da2000, 0x00da2fff] PGTABLE
[0.00] BRK [0x00da3000, 0x00da3fff] PGTABLE
[0.00] BRK [0x00da4000, 0x00da4fff] PGTABLE
[0.00] BRK [0x00da5000, 0x00da5fff] PGTABLE
[0.00] BRK [0x00da6000, 0x00da6fff] PGTABLE
[0.00] BRK [0x00da7000, 0x00da7fff] PGTABLE
[0.00] RAMDISK: [