Btrfs subvolume question

Btrfs subvolume question

[Markus Moeller]

Hi ,

   I am new to btrfs and wonder what I need to do to move subvolumes to the 
right filesystem.  I see the following:

df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /
devtmpfs                         235M  8.0K  235M   1% /dev
tmpfs                            242M   84K  242M   1% /dev/shm
tmpfs                            242M  2.4M  240M   1% /run
tmpfs                            242M     0  242M   0% /sys/fs/cgroup
/dev/mapper/system_13.2-usr_lv    18G  6.9G   10G  41% /usr
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /srv
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /.snapshots
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /tmp
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /usr/local
/dev/sda2                        486M   59M  398M  13% /boot
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% 
/boot/grub2/x86_64-efi
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /boot/grub2/i386-pc
/dev/mapper/export_vg-export_lv   20G   18G  2.9G  86% /export
/dev/mapper/export_vg-src_lv     5.0G  2.6G  2.5G  51% /src
/dev/mapper/system_13.2-var_lv   4.0G  196M  3.4G   6% /var
/dev/mapper/system_13.2-opt_lv   6.0G  152M  5.3G   3% /opt
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/spool
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/tmp
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/opt
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/log
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/named
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/mailman
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/pgsql


and I would like to have all the var subvolumes using the /var filesystem 
space and not root.   The same for /boot/grub2 subvolumes. They should use 
the /boot filesystem.   I don't know how I got to this and don't know how to 
change.

# cat /etc/fstab
UUID=d300b5ad-372b-4f86-b952-4aa4fc62a84e swap swap defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f / btrfs defaults 0 0
UUID=fd14684f-1950-4f33-95b5-b54f069b4fe0 /boot ext4 acl,user_xattr 1 2
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /boot/grub2/i386-pc btrfs 
subvol=boot/grub2/i386-pc 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /boot/grub2/x86_64-efi btrfs 
subvol=boot/grub2/x86_64-efi 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /home btrfs subvol=home 0 0
UUID=f535177b-18a5-443c-8236-96105d58a621 /opt btrfs defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /srv btrfs subvol=srv 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /tmp btrfs subvol=tmp 0 0
UUID=62ffc2f3-7e3a-433e-8a4e-5a89a352f8cf /usr btrfs defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /usr/local btrfs subvol=usr/local 
0 0
UUID=323ba68a-e7ed-4f0f-9716-dcad92bb9808 /var btrfs defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/crash btrfs subvol=var/crash 
0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/lib/mailman btrfs 
subvol=var/lib/mailman 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/lib/named btrfs 
subvol=var/lib/named 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/lib/pgsql btrfs 
subvol=var/lib/pgsql 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/log btrfs subvol=var/log 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/opt btrfs subvol=var/opt 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/spool btrfs subvol=var/spool 
0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/tmp btrfs subvol=var/tmp 0 0
/dev/export_vg/export_lv /export xfs defaults 1 2
/dev/export_vg/src_lv /src xfs defaults 1 2
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /.snapshots btrfs 
subvol=.snapshots 0 0

Thank you
Markus 

Re: Btrfs subvolume question

[Chris Murphy]

On Wed, Feb 4, 2015 at 3:54 PM, Markus Moeller <huaraz@moeller.plus.com> wrote:
> Hi ,
>
>   I am new to btrfs and wonder what I need to do to move subvolumes to the
> right filesystem.  I see the following:
>
> df -h
> Filesystem                       Size  Used Avail Use% Mounted on
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /
> devtmpfs                         235M  8.0K  235M   1% /dev
> tmpfs                            242M   84K  242M   1% /dev/shm
> tmpfs                            242M  2.4M  240M   1% /run
> tmpfs                            242M     0  242M   0% /sys/fs/cgroup
> /dev/mapper/system_13.2-usr_lv    18G  6.9G   10G  41% /usr
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /srv
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /.snapshots
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /tmp
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /usr/local
> /dev/sda2                        486M   59M  398M  13% /boot
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32%
> /boot/grub2/x86_64-efi
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /boot/grub2/i386-pc
> /dev/mapper/export_vg-export_lv   20G   18G  2.9G  86% /export
> /dev/mapper/export_vg-src_lv     5.0G  2.6G  2.5G  51% /src
> /dev/mapper/system_13.2-var_lv   4.0G  196M  3.4G   6% /var
> /dev/mapper/system_13.2-opt_lv   6.0G  152M  5.3G   3% /opt
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/spool
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/tmp
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/opt
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/log
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/named
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/mailman
> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/pgsql
>
>
> and I would like to have all the var subvolumes using the /var filesystem
> space and not root.  The same for /boot/grub2 subvolumes. They should use
> the /boot filesystem.

The giveaway is in the first column. All of these are device mapper
LVM LV's, they are not Btrfs subvolumes, in fact they're separate
Btrfs volumes (unique, unrelated filesystems). What's suspicious,
though, is that a bunch of these LV's have exactly 1.5G Used, which
makes no sense. For example, /boot/grub2/i386-pc has 1.5G used, but
that's not possible, the entire GRUB2 package is maybe 50MB.

Honestly, I suggest reinstalling and don't deal with the tricky task
of converting all of this. It'll take longer for me to explain, and
you to read, how to fix this without reinstalling. I also suggest
making sure that you don't put Btrfs on LVM, there's no good reason to
do this for most use cases.


 I don't know how I got to this and don't know how to
> change.

It's not your fault. This is a pathological side effect of openSUSE
13.2's, quite frankly bizarre, layout. By default it creates a single
Btrfs volume, and makes all of these subvolumes, which is strange
enough on its own because it's overly complicated (just look at
/etc/fstab) for no good reason. But somehow in your case, you ended up
with a bunch of LVM LVs first, and then each of those is a Btrfs
volume. If it were me, I'd file a bug report against 13.2, and then
file a feature request citing the bug report. If you don't want to do
both, then just file the feature request against Factory because
installer related bug reports on openSUSE basically get rejected
seeing as there's nothing that can be done about it in Distribution
now anyway.

-- 
Chris Murphy

Re: Btrfs subvolume question

[Robert White]

On 02/04/2015 06:27 PM, Chris Murphy wrote:
> On Wed, Feb 4, 2015 at 3:54 PM, Markus Moeller <huaraz@moeller.plus.com> wrote:
>> Hi ,
>>
>>    I am new to btrfs and wonder what I need to do to move subvolumes to the
>> right filesystem.  I see the following:
>>
>> df -h
>> Filesystem                       Size  Used Avail Use% Mounted on
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /
>> devtmpfs                         235M  8.0K  235M   1% /dev
>> tmpfs                            242M   84K  242M   1% /dev/shm
>> tmpfs                            242M  2.4M  240M   1% /run
>> tmpfs                            242M     0  242M   0% /sys/fs/cgroup
>> /dev/mapper/system_13.2-usr_lv    18G  6.9G   10G  41% /usr
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /srv
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /.snapshots
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /tmp
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /usr/local
>> /dev/sda2                        486M   59M  398M  13% /boot
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32%
>> /boot/grub2/x86_64-efi
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /boot/grub2/i386-pc
>> /dev/mapper/export_vg-export_lv   20G   18G  2.9G  86% /export
>> /dev/mapper/export_vg-src_lv     5.0G  2.6G  2.5G  51% /src
>> /dev/mapper/system_13.2-var_lv   4.0G  196M  3.4G   6% /var
>> /dev/mapper/system_13.2-opt_lv   6.0G  152M  5.3G   3% /opt
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/spool
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/tmp
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/opt
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/log
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/named
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/mailman
>> /dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /var/lib/pgsql
>>
>>
>> and I would like to have all the var subvolumes using the /var filesystem
>> space and not root.  The same for /boot/grub2 subvolumes. They should use
>> the /boot filesystem.
>
> The giveaway is in the first column. All of these are device mapper
> LVM LV's, they are not Btrfs subvolumes, in fact they're separate
> Btrfs volumes (unique, unrelated filesystems). What's suspicious,
> though, is that a bunch of these LV's have exactly 1.5G Used, which
> makes no sense. For example, /boot/grub2/i386-pc has 1.5G used, but
> that's not possible, the entire GRUB2 package is maybe 50MB.

Actually given that the first column repeats 
/dev/mapper/system_13.2-root_lv as the device, I think he's repeatedly 
mounted the same device filesystem with different subovol= directives.

That's why so many of them have the same 1.5G used.

In terms of actual LVs he only seems to have _root_ _opt_ _var_ and 
_usr_ once you strip away the various noise components.

In particular oddity fassion /var is a different device but /var/log 
goes back to the root device.

In a slightly over-thought way its kind of twisted genius if you view 
/var/lib/named and such as being tightly bound to /etc. (/var/tmp is 
totally wrong.)

It's not something I would want to maintain either.

They also might be bind mounts instead of subvol= mounts. I'd have to 
see /etc/fstab.

The output of btrfs subvol list  on / /var /usr and /opt would be nice 
as well.


>
> Honestly, I suggest reinstalling and don't deal with the tricky task
> of converting all of this. It'll take longer for me to explain, and
> you to read, how to fix this without reinstalling. I also suggest
> making sure that you don't put Btrfs on LVM, there's no good reason to
> do this for most use cases.
>
>
>   I don't know how I got to this and don't know how to
>> change.
>
> It's not your fault. This is a pathological side effect of openSUSE
> 13.2's, quite frankly bizarre, layout. By default it creates a single
> Btrfs volume, and makes all of these subvolumes, which is strange
> enough on its own because it's overly complicated (just look at
> /etc/fstab) for no good reason. But somehow in your case, you ended up
> with a bunch of LVM LVs first, and then each of those is a Btrfs
> volume. If it were me, I'd file a bug report against 13.2, and then
> file a feature request citing the bug report. If you don't want to do
> both, then just file the feature request against Factory because
> installer related bug reports on openSUSE basically get rejected
> seeing as there's nothing that can be done about it in Distribution
> now anyway.
>

Re: Btrfs subvolume question

[Chris Murphy]

On Wed, Feb 4, 2015 at 8:40 PM, Robert White <rwhite@pobox.com> wrote:
> In terms of actual LVs he only seems to have _root_ _opt_ _var_ and _usr_
> once you strip away the various noise components.

I think you win the prize on this. I saw that, and ignored the fact
the LV name was identical for so many of these mount points.

> In particular oddity fassion /var is a different device but /var/log goes
> back to the root device.

Yes. And so do

/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /boot/grub2/x86_64-efi
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /boot/grub2/i386-pc

> They also might be bind mounts instead of subvol= mounts. I'd have to see
> /etc/fstab.
>
> The output of btrfs subvol list  on / /var /usr and /opt would be nice as
> well.

The fstab would pretty much reveal the whole story.

The intended Btrfs only layout on openSUSE actually causes a  big
problem for the Fedora installer right now. A combination of many
subvolumes and snapshots taken by default, and the way the Fedora
installer UI presents and makes them essentially impossible to remove
as a whole volume.
https://bugzilla.redhat.com/show_bug.cgi?id=1185117

This is the inevitable outcome of distributions not coming to a sane
consensus on a boot loading specification, made worse by no consensus
on how to manage/name snapshots and assemble things at boot time.
Everyone has their own idea being implemented so we get even more
fragmentation as if these are different operating systems that just so
happen to share a kernel.

So this is just the beginning of crazy installer behaviors and
pathological problems due to lack of distributions getting along at
anything above the kernel (and systemd). I actually like the
subvolume/snapshot naming convention suggested here:
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
The ability to migrate such layout between systems is a lot more
functional, discoverable, and cleaner than either Fedora's root, boot,
home subvolumes method; or openSUSE's let's make 18 subvolumes that no
one will like to manually btrfs send/receive more than once in their
lifetime, assuming reading the fstab doesn't cause a pill popping
episode.

-- 
Chris Murphy

Re: Btrfs subvolume question

[Markus Moeller]

Thank you for looking at this.  I did post the fstab  in the original post. 
Here it is again:

# cat /etc/fstab
UUID=d300b5ad-372b-4f86-b952-4aa4fc62a84e swap swap defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f / btrfs defaults 0 0
UUID=fd14684f-1950-4f33-95b5-b54f069b4fe0 /boot ext4 acl,user_xattr 1 2
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /boot/grub2/i386-pc btrfs 
subvol=boot/grub2/i386-pc 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /boot/grub2/x86_64-efi btrfs 
subvol=boot/grub2/x86_64-efi 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /home btrfs subvol=home 0 0
UUID=f535177b-18a5-443c-8236-96105d58a621 /opt btrfs defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /srv btrfs subvol=srv 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /tmp btrfs subvol=tmp 0 0
UUID=62ffc2f3-7e3a-433e-8a4e-5a89a352f8cf /usr btrfs defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /usr/local btrfs subvol=usr/local 
0 0
UUID=323ba68a-e7ed-4f0f-9716-dcad92bb9808 /var btrfs defaults 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/crash btrfs subvol=var/crash 
0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/lib/mailman btrfs 
subvol=var/lib/mailman 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/lib/named btrfs 
subvol=var/lib/named 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/lib/pgsql btrfs 
subvol=var/lib/pgsql 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/log btrfs subvol=var/log 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/opt btrfs subvol=var/opt 0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/spool btrfs subvol=var/spool 
0 0
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /var/tmp btrfs subvol=var/tmp 0 0
/dev/export_vg/export_lv /export xfs defaults 1 2
/dev/export_vg/src_lv /src xfs defaults 1 2
UUID=7a681ad4-5b82-4e78-9b20-1d719c89fe6f /.snapshots btrfs 
subvol=.snapshots 0 0


The only thing I intended was to separate /,  /var, /opt, /usr and /boot as 
I was used to, to avoid for example /var/log filling up the root filesystem 
( but now this fails :-( )

Markus

"Chris Murphy"  wrote in message 
news:CAJCQCtSLBg7-XoVjTfDq5PbZ-dk1WXeXGT2YEbQYNNc0VoSu-A@mail.gmail.com...

On Wed, Feb 4, 2015 at 8:40 PM, Robert White <rwhite@pobox.com> wrote:
> In terms of actual LVs he only seems to have _root_ _opt_ _var_ and _usr_
> once you strip away the various noise components.

I think you win the prize on this. I saw that, and ignored the fact
the LV name was identical for so many of these mount points.

> In particular oddity fassion /var is a different device but /var/log goes
> back to the root device.

Yes. And so do

/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% 
/boot/grub2/x86_64-efi
/dev/mapper/system_13.2-root_lv  5.0G  1.5G  3.2G  32% /boot/grub2/i386-pc

> They also might be bind mounts instead of subvol= mounts. I'd have to see
> /etc/fstab.
>
> The output of btrfs subvol list  on / /var /usr and /opt would be nice as
> well.

The fstab would pretty much reveal the whole story.

The intended Btrfs only layout on openSUSE actually causes a  big
problem for the Fedora installer right now. A combination of many
subvolumes and snapshots taken by default, and the way the Fedora
installer UI presents and makes them essentially impossible to remove
as a whole volume.
https://bugzilla.redhat.com/show_bug.cgi?id=1185117

This is the inevitable outcome of distributions not coming to a sane
consensus on a boot loading specification, made worse by no consensus
on how to manage/name snapshots and assemble things at boot time.
Everyone has their own idea being implemented so we get even more
fragmentation as if these are different operating systems that just so
happen to share a kernel.

So this is just the beginning of crazy installer behaviors and
pathological problems due to lack of distributions getting along at
anything above the kernel (and systemd). I actually like the
subvolume/snapshot naming convention suggested here:
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
The ability to migrate such layout between systems is a lot more
functional, discoverable, and cleaner than either Fedora's root, boot,
home subvolumes method; or openSUSE's let's make 18 subvolumes that no
one will like to manually btrfs send/receive more than once in their
lifetime, assuming reading the fstab doesn't cause a pill popping
episode.

-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Btrfs subvolume question

[Chris Murphy]

On Thu, Feb 5, 2015 at 1:28 PM, Markus Moeller <huaraz@moeller.plus.com> wrote:
> Thank you for looking at this.  I did post the fstab  in the original post.

Yep! No aware for my observation skills on this thread...

> Here it is again:

Hmm, it's using UUIDs for the Btrfs volumes rather than using the
VG/LV. If you use

# lvs

that'll show the LVM LV's. But Robert already got this figured out.


> The only thing I intended was to separate /,  /var, /opt, /usr and /boot as
> I was used to, to avoid for example /var/log filling up the root filesystem
> ( but now this fails :-( )

/var/log is on system_13.2/root_lv along with a bunch of other things.
According to your first df though, this 5GB root_lv is far from full,
not even 1/2 full. So I don't have a good explanation.

Anyway, long term this layout has maintenance problems, I would start
over. Backing up, restoring, even updating will pose problematic.



-- 
Chris Murphy

Re: Btrfs subvolume question

[Markus Moeller]

It seems systemd creates the subvolumes.

> cat /run/systemd/generator/local-fs.target.requires/var-opt.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Before=local-fs.target

[Mount]
What=/dev/disk/by-uuid/7a681ad4-5b82-4e78-9b20-1d719c89fe6f
Where=/var/opt
Type=btrfs
Options=subvol=var/opt


Markus

"Chris Murphy"  wrote in message 
news:CAJCQCtT1pSrFEU7Q0qspNkqzY9naDHxzzyE5y3fyqgZqqkT_vA@mail.gmail.com...

On Thu, Feb 5, 2015 at 1:28 PM, Markus Moeller <huaraz@moeller.plus.com> 
wrote:
> Thank you for looking at this.  I did post the fstab  in the original 
> post.

Yep! No aware for my observation skills on this thread...

> Here it is again:

Hmm, it's using UUIDs for the Btrfs volumes rather than using the
VG/LV. If you use

# lvs

that'll show the LVM LV's. But Robert already got this figured out.


> The only thing I intended was to separate /,  /var, /opt, /usr and /boot 
> as
> I was used to, to avoid for example /var/log filling up the root 
> filesystem
> ( but now this fails :-( )

/var/log is on system_13.2/root_lv along with a bunch of other things.
According to your first df though, this 5GB root_lv is far from full,
not even 1/2 full. So I don't have a good explanation.

Anyway, long term this layout has maintenance problems, I would start
over. Backing up, restoring, even updating will pose problematic.



-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Btrfs subvolume question

[Chris Murphy]

On Thu, Feb 5, 2015 at 3:49 PM, Markus Moeller <huaraz@moeller.plus.com> wrote:
>
> It seems systemd creates the subvolumes.
>
>> cat /run/systemd/generator/local-fs.target.requires/var-opt.mount
>
> # Automatically generated by systemd-fstab-generator


Nope, the job of systemd-fstab-generator is to read fstab and create
native systemd units to cause the mounting to happen.

-- 
Chris Murphy

Re: Btrfs subvolume question

[Markus Moeller]

So what I don't understand which process created the sub volumes. I fear if 
I start again it will be the same.  The OpenSuse YAST2 Partition tool does 
not show any subvolumes.

Thank you
Markus

"Chris Murphy"  wrote in message 
news:CAJCQCtRHsiau97r66O9PC6O0mK7Yafc3aE2HX=4bT-w4nw8OZg@mail.gmail.com...

On Thu, Feb 5, 2015 at 3:49 PM, Markus Moeller <huaraz@moeller.plus.com> 
wrote:
>
> It seems systemd creates the subvolumes.
>
>> cat /run/systemd/generator/local-fs.target.requires/var-opt.mount
>
> # Automatically generated by systemd-fstab-generator


Nope, the job of systemd-fstab-generator is to read fstab and create
native systemd units to cause the mounting to happen.

-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Btrfs subvolume question

[Chris Murphy]

On Fri, Feb 6, 2015 at 3:29 PM, Markus Moeller <huaraz@moeller.plus.com> wrote:
> So what I don't understand which process created the sub volumes.

Yast had to have done it. It did all the partitioning, creation of the
file system, and it created fstab.


> I fear if
> I start again it will be the same.

Don't check the LVM option. I don't have the installer UI right in
front of me so I don't know exactly where it is or what it's called,
but it's not enabled by default because I've done a default openSUSE
13.2 installation and it did use Btrfs and created a pile of
subvolumes, but it didn't use LVM at all.


> The OpenSuse YAST2 Partition tool does
> not show any subvolumes.

That sounds like a feature request. They're clearly there.



-- 
Chris Murphy