Re: Is btrfs-convert able to deal with sparse files in a ext4 filesystem?

2017-04-07 Thread Kai Herlemann
Hi @all who answered,
thank for your help and please excuse my late answer. I didn't see
your answers because of misconfiguration of my GMail filter for that
list.
The filesystem contains backups of some other filesystems (it's on a
external storage which is mirrored by RAID 1). So, if the filesystem
get lost, there are still the source partitions of the backups. But
you're right, I have to have actually more space purposes like using
btrfs-convert, which needs a backup, but can't/want afford that at the
moment because I'm student.

As far as I remember, I used in the past btrfs-convert to convert the
ext4 root partition of my laptop. It didn't really work with old
versions of btrfs-progs (I rollbacked it then or imported a backup),
but it worked with 4.4 or so.
Nevertheless, I won't use btrfs-convert after your warnings, and will
create a new filesystem and copy the data from ext4 to btrfs when I
have enough space.

Thank you all,
Kai
--
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


Is btrfs-convert able to deal with sparse files in a ext4 filesystem?

2017-04-01 Thread Kai Herlemann
Hi,
I have on my ext4 filesystem some sparse files, mostly images from
ext4 filesystems.
Is btrfs-convert (4.9.1) able to deal with sparse files or can that
cause any problems?

Thanks in advance,
Kai
--
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: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Kai Herlemann

Am 07.07.2016 um 19:40 schrieb Chris Murphy:

And very clearly from the OP's output from 'btrfs sub list' there are
no subvolumes with @ in the path, so there is no subvolume @, nor are
there any subvolumes contained in a directory @.

[...]

Anyway the reason why the command fails is stated in the error
message. The system appears to be installed in the top level of the
file system (subvolid=5), and that can't be deleted. First it's the
immutable first subvolume of a Btrfs file system, and second it's
populated with other subvolumes which would inhibit its removal even
if it weren't the top level subvolume.

What can be done is delete the directories in the top level, retaining
the subvolumes that are there.
Thank you, that was it: there was really no subvolume named @ existing. 
Thank you to Henk and Andrei, too.
I didn't believed that, although there was no @ from ot the output of 
"btrfs sub list", because all websites that dealt with this topic and 
which I used for research statet that a subvolume named @ would 
automatically be created (or I misunderstood the sites), and secondly, 
because the ID of the top level volume is in my case 5, and I 
(mis)understand, in cases where's the subvolume "@" automatically 
created, the ID of that subvolume would be also 5.
I created now myself a subvolume "@" on the top level volume, moved then 
all the data from the snapshot, which I used the last days, to the new 
subvolume, and deleted then all data from the top level volume, except 
the sub level volume @ of course, and made previously a backup snapshot 
from the top level volume. Other users who reading later here and want 
to move their data from top level volume should able to do the same.


If here any developers read along: I'd like to suggest that there's 
automatically made a subvolume "@" by default, which is set as default 
subvolume, or a tip to the distribution, that it would made sense to do 
that with the installation. It would protect other users against 
confusion and work like I had it.


Thank you,
Kai
--
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


rollback to a snapshot and delete old top volume - missing of "@"

2016-07-07 Thread Kai Herlemann

Hi,

I want to rollback a snapshot and have done this by execute "btrfs sub 
set-default / 618".
Now I want to delete the old top volume to save space, but google and 
manuals didn't helped.


I mounted for the following the root volume at /mnt/gparted with 
subvolid=0, subvol=/ has the same effect.
Usually, the top volume is saved in /@, so I would be able to delete it 
by execute "btrfs sub delete /@" (or move at first @ to @_badroot and 
the snapshot to @). But that isn't possible, the output of that command 
is "ERROR: cannot access subvolume /@: No such file or directory".
I've posted the output of "btrfs sub list /mnt/gparted" at 
http://pastebin.com/r7WNbJq8. As you can see, there's no subvolume named @.


I have the same problem with my /home/ partition.

Output of "uname -a" (self-compiled kernel):
Linux debian-linux 4.1.26 #1 SMP Wed Jun 8 18:40:04 CEST 2016 x86_64 
GNU/Linux


Output of "btrfs --version":
btrfs-progs v4.5.2

Output of "btrfs fi show":
Label: none  uuid: f778877c-d50b-48c8-8951-6635c6e23c61
  Total devices 1 FS bytes used 43.70GiB
  devid1 size 55.62GiB used 47.03GiB path /dev/sda1

Output of "btrfs fi df /":
Data, single: total=44.00GiB, used=42.48GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=3.00GiB, used=1.22GiB
GlobalReserve, single: total=416.00MiB, used=0.00B

Output of dmesg attached.

Thank you,
Kai

[0.00] microcode: CPU0 microcode updated early to revision 0xe, date = 2013-06-26
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.1.26 (root@debian-linux) (gcc version 5.3.1 20160528 (Debian 5.3.1-21) ) #1 SMP Wed Jun 8 18:40:04 CEST 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.26 root=UUID=f778877c-d50b-48c8-8951-6635c6e23c61 ro resume=UUID=9be0bf62-859d-42cb-b075-4bd31f41c53d init=/lib/systemd/systemd
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9f680fff] usable
[0.00] BIOS-e820: [mem 0x9f681000-0x9f6befff] reserved
[0.00] BIOS-e820: [mem 0x9f6bf000-0x9f735fff] usable
[0.00] BIOS-e820: [mem 0x9f736000-0x9f7befff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9f7bf000-0x9f7defff] usable
[0.00] BIOS-e820: [mem 0x9f7df000-0x9f7fefff] ACPI data
[0.00] BIOS-e820: [mem 0x9f7ff000-0x9f7f] usable
[0.00] BIOS-e820: [mem 0x9f80-0x9fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved
[0.00] BIOS-e820: [mem 0xfed18000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1b000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000157ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: eMachineseME730G /eME730G , BIOS V1.23 04/25/2011
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x158000 max_arch_pfn = 0x4
[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-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 0FFE0 mask FFFE0 write-protect
[0.00]   2 base 08000 mask FE000 write-back
[0.00]   3 base 09F80 mask FFF80 uncachable
[0.00]   4 base 1 mask FC000 write-back
[0.00]   5 base 14000 mask FF000 write-back
[0.00]   6 base 15000 mask FF800 write-back
[0.00]   7 disabled
[0.00] PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC  
[0.00] e820: last_pfn = 0x9f800 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x00