* Btrfs subvolume question @ 2015-02-04 22:54 Markus Moeller 2015-02-05 2:27 ` Chris Murphy 0 siblings, 1 reply; 10+ messages in thread From: Markus Moeller @ 2015-02-04 22:54 UTC (permalink / raw) To: linux-btrfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-04 22:54 Btrfs subvolume question Markus Moeller @ 2015-02-05 2:27 ` Chris Murphy 2015-02-05 3:40 ` Robert White 0 siblings, 1 reply; 10+ messages in thread From: Chris Murphy @ 2015-02-05 2:27 UTC (permalink / raw) To: Markus Moeller; +Cc: Btrfs BTRFS 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-05 2:27 ` Chris Murphy @ 2015-02-05 3:40 ` Robert White 2015-02-05 6:03 ` Chris Murphy 0 siblings, 1 reply; 10+ messages in thread From: Robert White @ 2015-02-05 3:40 UTC (permalink / raw) To: Chris Murphy, Markus Moeller; +Cc: Btrfs BTRFS 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. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-05 3:40 ` Robert White @ 2015-02-05 6:03 ` Chris Murphy 2015-02-05 20:28 ` Markus Moeller 0 siblings, 1 reply; 10+ messages in thread From: Chris Murphy @ 2015-02-05 6:03 UTC (permalink / raw) To: Robert White; +Cc: Chris Murphy, Markus Moeller, Btrfs BTRFS 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-05 6:03 ` Chris Murphy @ 2015-02-05 20:28 ` Markus Moeller 2015-02-05 20:58 ` Chris Murphy 0 siblings, 1 reply; 10+ messages in thread From: Markus Moeller @ 2015-02-05 20:28 UTC (permalink / raw) To: linux-btrfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-05 20:28 ` Markus Moeller @ 2015-02-05 20:58 ` Chris Murphy 2015-02-05 22:49 ` Markus Moeller 0 siblings, 1 reply; 10+ messages in thread From: Chris Murphy @ 2015-02-05 20:58 UTC (permalink / raw) To: Markus Moeller; +Cc: Btrfs BTRFS 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-05 20:58 ` Chris Murphy @ 2015-02-05 22:49 ` Markus Moeller 2015-02-06 3:05 ` Chris Murphy 0 siblings, 1 reply; 10+ messages in thread From: Markus Moeller @ 2015-02-05 22:49 UTC (permalink / raw) To: linux-btrfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-05 22:49 ` Markus Moeller @ 2015-02-06 3:05 ` Chris Murphy 2015-02-06 22:29 ` Markus Moeller 0 siblings, 1 reply; 10+ messages in thread From: Chris Murphy @ 2015-02-06 3:05 UTC (permalink / raw) To: Markus Moeller; +Cc: Btrfs BTRFS 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-06 3:05 ` Chris Murphy @ 2015-02-06 22:29 ` Markus Moeller 2015-02-07 0:14 ` Chris Murphy 0 siblings, 1 reply; 10+ messages in thread From: Markus Moeller @ 2015-02-06 22:29 UTC (permalink / raw) To: linux-btrfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Btrfs subvolume question 2015-02-06 22:29 ` Markus Moeller @ 2015-02-07 0:14 ` Chris Murphy 0 siblings, 0 replies; 10+ messages in thread From: Chris Murphy @ 2015-02-07 0:14 UTC (permalink / raw) To: Markus Moeller, Btrfs BTRFS 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-02-07 0:14 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-02-04 22:54 Btrfs subvolume question Markus Moeller 2015-02-05 2:27 ` Chris Murphy 2015-02-05 3:40 ` Robert White 2015-02-05 6:03 ` Chris Murphy 2015-02-05 20:28 ` Markus Moeller 2015-02-05 20:58 ` Chris Murphy 2015-02-05 22:49 ` Markus Moeller 2015-02-06 3:05 ` Chris Murphy 2015-02-06 22:29 ` Markus Moeller 2015-02-07 0:14 ` Chris Murphy
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).