[opensuse-factory] btrfs root - why so many subvolumes?
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var. Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) : http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu... Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs? Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice? Regards, Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pondělí 17. října 2016 21:49:19 CEST, Michael Hamilton napsal(a):
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Really? E.g. /var/lib/mariadb is better to handle with tools like automysqlbackup anyway. I see it OK.
Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) :
Is this enough? https://www.suse.com/documentation/sles-12/stor_admin/data/ sec_filesystems_major.html
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu se-fstab-contain-so-many-btrfs-subvol-entries
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
I don't know if recommended, but dd?
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
Then I'd keep Btrfs anyway - its possibility of snapshots, i.e. possibility to roll back to previous version from many failures (power outage in the middle of big upgrade etc.) is really great. The subvolumes typically exclude quickly changing temporary, DB, cache, ... directories from snapshots to save space and the disk. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On 10/17/2016 06:13 AM, Vojtěch Zeisek wrote:
The subvolumes typically exclude quickly changing temporary, DB, cache, ... directories from snapshots to save space and the disk.
Yes but what about 'filters as in /etc/snapper/filters ?? # ls /etc/snapper/filters/ base.txt logfiles.txt lvm.txt x11.txt Is this another exclusion mechanism? I can't, on a quick read, find mention of this in the man page on snapper-config. -- When languishing for solutions, don't ask "Have I got the correct answer?" The correct question is "Have I got the correct question?" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On lundi, 17 octobre 2016 21.49:19 h CEST Michael Hamilton wrote:
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) :
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu se-fstab-contain-so-many-btrfs-subvol-entries
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
Regards, Michael
From my experience, I'm a btrfs breaker guy (The why has still to be determined :-) ). So for my own laptop, I using the traditionnal luks encrypted vg/lvm + lvm with ext4, this as been rock solid for my own usage, even when I trash the power outlet. But there's a downside, I'm not using snapper/ext4) and then loose the ability to use a rollback snapshot. I have to be careful when doing update with TW. ;-) The main reason of having that much subvolume from some clues I got from internet is for example, that there's no way to have checksum (interesting for database for example) without cow (copy on write, which is not interesting for database). The nocow flag disable also checksumming. (beware those informations can be outdated since I've test them 6-8 months ago) Also subvol are related also to quota. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/2016 08:54 PM, Bruno Friedmann wrote:
On lundi, 17 octobre 2016 21.49:19 h CEST Michael Hamilton wrote:
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) :
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu se-fstab-contain-so-many-btrfs-subvol-entries
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
Regards, Michael
From my experience, I'm a btrfs breaker guy (The why has still to be determined :-) ). So for my own laptop, I using the traditionnal luks encrypted vg/lvm + lvm with ext4, this as been rock solid for my own usage, even when I trash the power outlet. But there's a downside, I'm not using snapper/ext4) and then loose the ability to use a rollback snapshot. I have to be careful when doing update with TW.
;-)
The main reason of having that much subvolume from some clues I got from internet is for example, that there's no way to have checksum (interesting for database for example) without cow (copy on write, which is not interesting for database). The nocow flag disable also checksumming. (beware those informations can be outdated since I've test them 6-8 months ago) Also subvol are related also to quota.
The other reason is to avoid the data being captured in a disk snapshot that can be used too roll back later, for example generally if you need to roll back to a earlier snapshot to recover your system rolling back the contents of /tmp /var/cache etc is not useful. You also wouldn't want to roll back /var/logs as you'd loose data. By having these in a separate snapshot this wont happen. Also someone has now answered the stack overflow question covering both these reasons. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2016-10-17 13:59, Simon Lees wrote:
The other reason is to avoid the data being captured in a disk snapshot that can be used too roll back later, for example generally if you need to roll back to a earlier snapshot to recover your system rolling back the contents of /tmp /var/cache etc is not useful. You also wouldn't want to roll back /var/logs as you'd loose data. By having these in a separate snapshot this wont happen.
Yes. It would be nice if there were a script or something to create all those volumes, used during installation, so that the admin could recreate them easily. Or a function in the YaST partitioner module to create that layout in a new or existing empty btrfs partition without doing an install. Just an idea :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tue, 18 Oct 2016, Carlos E. R. wrote:
On 2016-10-17 13:59, Simon Lees wrote:
The other reason is to avoid the data being captured in a disk snapshot that can be used too roll back later, for example generally if you need to roll back to a earlier snapshot to recover your system rolling back the contents of /tmp /var/cache etc is not useful. You also wouldn't want to roll back /var/logs as you'd loose data. By having these in a separate snapshot this wont happen.
Yes.
It would be nice if there were a script or something to create all those volumes, used during installation, so that the admin could recreate them easily.
Or a function in the YaST partitioner module to create that layout in a new or existing empty btrfs partition without doing an install.
Just an idea :-)
Yes, this would be quite useful. It would then be straight forward to use snapper to create a snapshot, rsync the snapshot to the new structure and then followup with an rsync of any subvolumes that should also be backed up. This would also make cpio/tar based backups more straight forward. Regards, Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Oct 17 14:32 Carlos E. R. wrote (excerpt):
It would be nice if there were a script or something to create all those volumes, used during installation, so that the admin could recreate them easily.
There is something like that but only to create a single subvolume and currently its usefulness is limited on SLE12 and Leap 42.1 (perhaps it gets better on Tumbleweed): /usr/sbin/mksubvolume (it belongs to the snapper RPM) See "man mksubvolume". What is currently missing is that mksubvolume creates parent directories as needed: --------------------------------------------------------- # mksubvolume /var/mystuff/mysubvol failure (parent of target does not exist) --------------------------------------------------------- In this case a manual "mkdir /var/mystuff/" is needed: --------------------------------------------------------- # mkdir /var/mystuff # mksubvolume /var/mystuff/mysubvol --------------------------------------------------------- What is currently also missing is that mksubvolume can correctly remove such a subvolume because only something like "btrfs subvolume delete /var/mystuff/mysubvol" is insufficient and it does not work this way: --------------------------------------------------------------- # btrfs subvolume delete /var/mystuff/mysubvol Delete subvolume (no-commit): '/var/mystuff/mysubvol' ERROR: cannot delete '/var/mystuff/mysubvol': Invalid argument --------------------------------------------------------------- It is more complicated to delete such a subvolume, cf: ------------------------------------------------------------------- # btrfs subvolume list -a / | grep mystuff ID 306 gen 5933 top level 257 path <FS_TREE>/@/var/mystuff/mysubvol ------------------------------------------------------------------- I leave it to the reader to find out how to delete such a subvolume (hint: inspect my script below ;-) But if only the subvolume is deleted it leads to "interesting effects" during the next reboot: You will find yourself in systemd's emergency mode because the /var/mystuff/mysubvol entry in /etc/fstab is still there but that one cannot be mounted (because the subvolume is deleted). Solution is to manually remove the /var/mystuff/mysubvol entry from /etc/fstab. Caution: What results totally wrongly created subvolumes for the SLE12 default btrfs subvolume structure is: -------------------------------------------------------------------------------- # btrfs subvolume create /var/mystuff/mysubvol2 Create subvolume '/var/mystuff/mysubvol2' # btrfs subvolume list -a / | grep mystuff ID 307 gen 5945 top level 259 path @/.snapshots/1/snapshot/var/mystuff/mysubvol2 -------------------------------------------------------------------------------- It is created under @/.snapshots/1/snapshot/ which is plain wrong. Better delete that subvolume right now: ---------------------------------------------------------- # btrfs subvolume delete /var/mystuff/mysubvol2 Delete subvolume (no-commit): '/var/mystuff/mysubvol2' ---------------------------------------------------------- FYI: Mainly for documentation here my selfmade script that I used on SLE12 before I learned that /usr/sbin/mksubvolume exits. This script shows how complicate it is to cerate a subvolume in compliance with the SLE12 default btrfs subvolume structure (long lines may get shown wrapped via e-mail): ------------------------------------------------------------------------- #!/bin/bash set -u -e -o pipefail # the code below fails if there is a leading slash: mysubvol=${1#/} # find out what subvolume on what device node is mounted at '/': output=( $(findmnt -nrv -t btrfs -o TARGET,SOURCE,FSROOT | grep '^/ ' ) ) # TARGET is '/' (by grep) # SOURCE is the device node that is mounted at the target '/': device=${output[1]} # FSROOT is the subvolume that is mounted at the target '/': fsroot=${output[2]} # if a '/@/.snapshots/...' subvolume is mounted at the target '/' # we assume the SLE12 btrfs default structure is used: if [[ $fsroot == "/@/.snapshots/"* ]] ; then # mount btrfs at its root subvolume: btrfsroot=$( mktemp -d /tmp/btrfsroot.XXXXXXXXXX ) mount -t btrfs -o subvolid=0 $device $btrfsroot # create subvolume under /@/: mkdir -p $btrfsroot/@/$( dirname $mysubvol ) btrfs subvolume create $btrfsroot/@/$mysubvol # btrfs at its root subvolume is no longer needed: umount $btrfsroot rmdir $btrfsroot # mount subvolume: output=( $( btrfs subvolume list -a / | grep "/@/$mysubvol" ) ) id=${output[1]} mkdir -p /$mysubvol mount -t btrfs -o subvolid=$id $device /$mysubvol # make entry in /etc/fstab: if ! grep -q "subvol=@/$mysubvol" /etc/fstab ; then uuid=$( for l in /dev/disk/by-uuid/* ; do readlink -e $l | grep -q $device && basename $l ; done ) echo "UUID=$uuid /$mysubvol btrfs subvol=@/$mysubvol 0 0" >>/etc/fstab fi else echo "Unexpected exit: No '/@/.snapshots/...' subvolume mounted at '/'." exit 99 fi ------------------------------------------------------------------------- This script is only my personal hack that I used for SLE12. It seemed to work for me on SLE12 but I have not at all tested it thoroughly and I never used it on Leap or Tumbleweed. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Okt 18 2016, Johannes Meixner <jsmeix@suse.de> wrote:
# find out what subvolume on what device node is mounted at '/': output=( $(findmnt -nrv -t btrfs -o TARGET,SOURCE,FSROOT | grep '^/ ' ) ) output=( $(findmnt -nrv -t btrfs -o TARGET,SOURCE,FSROOT /) )
Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Oct 18 10:22 Andreas Schwab wrote (excerpt):
On Okt 18 2016, Johannes Meixner <jsmeix@suse.de> wrote:
# find out what subvolume on what device node is mounted at '/': output=( $(findmnt -nrv -t btrfs -o TARGET,SOURCE,FSROOT | grep '^/ ' ) ) output=( $(findmnt -nrv -t btrfs -o TARGET,SOURCE,FSROOT /) )
Only a little bit better. Good: ----------------------------------------------------------------- # find out what subvolume on what device node is mounted at '/': output=( $(findmnt -nrv -t btrfs -o SOURCE,FSROOT / ) ) # SOURCE is the device node that is mounted at '/': device=${output[0]} # FSROOT is the subvolume that is mounted at '/': fsroot=${output[1]} ----------------------------------------------------------------- But I think optimization of my quick personal hack script is not the main goal here. I think best would be a /usr/sbin/mksubvolume tool that provides all needed functionality. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 17 October 2016 21:49:19 Michael Hamilton wrote:
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) :
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu se-fstab-contain-so-many-btrfs-subvol-entries
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
Having a low-level copy with dd should not be a problem. On the other hand, rsync'ing the content from a btrfs volume including all subvolumes to another volume regardless of the filesystem will copy the content and should work, without subvolumes, of course. IMHO the openSUSE default of btrfs is a very good choice for a desktop system, ext4 is no better in general, that's why btrfs *is* the default choice :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
IMHO the openSUSE default of
btrfs is a very good choice for a desktop system, ext4 is no better in general, that's why btrfs *is* the default choice :-)
May I ask why then /home is proposed with xfs ? ;-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
IMHO the openSUSE default of
btrfs is a very good choice for a desktop system, ext4 is no better in general, that's why btrfs *is* the default choice :-)
May I ask why then /home is proposed with xfs ? ;-)
I think because /home has so many quickly changing files it'd produce huge snapshots and fragmentation. It is better to use another tools to backup Your home. When there is no separate XFS /home partition, then there is Btrfs subvolume to exclude snapshoting. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On lundi, 17 octobre 2016 14.44:44 h CEST Vojtěch Zeisek wrote:
Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
IMHO the openSUSE default of
btrfs is a very good choice for a desktop system, ext4 is no better in general, that's why btrfs *is* the default choice :-)
May I ask why then /home is proposed with xfs ? ;-)
I think because /home has so many quickly changing files it'd produce huge snapshots and fragmentation. It is better to use another tools to backup Your home. When there is no separate XFS /home partition, then there is Btrfs subvolume to exclude snapshoting.
I know a system tool that produce a lot of changes too :-) journald One of the use case I would like to see covered is the use of btrfs + samba4 this (at least for me on paper) offering nice feature like move file on server side, snapshots for end user to have x version of their files etc. But ultimately, then how to save properly a snapshot to be able to restore a system in a point in time ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pondělí 17. října 2016 16:38:23 CEST, Bruno Friedmann napsal(a):
On lundi, 17 octobre 2016 14.44:44 h CEST Vojtěch Zeisek wrote:
Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
IMHO the openSUSE default of
btrfs is a very good choice for a desktop system, ext4 is no better in general, that's why btrfs *is* the default choice :-)
May I ask why then /home is proposed with xfs ? ;-)
I think because /home has so many quickly changing files it'd produce huge snapshots and fragmentation. It is better to use another tools to backup Your home. When there is no separate XFS /home partition, then there is Btrfs subvolume to exclude snapshoting.
I know a system tool that produce a lot of changes too :-) journald
Yes, logs are also in excluded subvolume. ;-)
One of the use case I would like to see covered is the use of btrfs + samba4 this (at least for me on paper) offering nice feature like move file on server side, snapshots for end user to have x version of their files etc.
I have similar principle to keep backups on the server - separated disc has Btrfs. Make a snapshot and rsync current data on it. Like this one has incremental (in our case daily) backups of whole user directory.
But ultimately, then how to save properly a snapshot to be able to restore a system in a point in time ?
https://en.opensuse.org/Portal:Snapper https://doc.opensuse.org/documentation/leap/reference/html/ book.opensuse.reference/cha.snapper.html -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On 17 October 2016 at 14:44, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
IMHO the openSUSE default of
btrfs is a very good choice for a desktop system, ext4 is no better in general, that's why btrfs *is* the default choice :-)
May I ask why then /home is proposed with xfs ? ;-)
I think because /home has so many quickly changing files it'd produce huge snapshots and fragmentation. It is better to use another tools to backup Your home. When there is no separate XFS /home partition, then there is Btrfs subvolume to exclude snapshoting.
Pretty accurate Also, when you are not benefiting from snapshotting, XFS is a little faster in a broader collection of use cases, such as those you see in /home, so it's a good default choice for /home Personally on my systems with a single disk/SSD I'm BTRFS all the way, because I don't like the additional complexity of managing partitions, especially when btrfs subvolumes gives me most of the controls I actually want XFS is only my filesystem of choice on dedicated data disks Which is pretty well aligned with what the openSUSE default is encoraging.. btrfs for root, XFS for data. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-10-17 17:02, Richard Brown wrote:
Personally on my systems with a single disk/SSD I'm BTRFS all the way, because I don't like the additional complexity of managing partitions, especially when btrfs subvolumes gives me most of the controls I actually want
What about installation of new version, keeping home intact? YaST normally would format the system partition and keep /home. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 17.10.16 21:09 Carlos E. R. wrote:
On 2016-10-17 17:02, Richard Brown wrote:
Personally on my systems with a single disk/SSD I'm BTRFS all the way, because I don't like the additional complexity of managing partitions, especially when btrfs subvolumes gives me most of the controls I actually want
What about installation of new version, keeping home intact? YaST normally would format the system partition and keep /home.
And what exactly is your question? Johannes
On 2016-10-18 20:12, Johannes Kastl wrote:
On 17.10.16 21:09 Carlos E. R. wrote:
On 2016-10-17 17:02, Richard Brown wrote:
Personally on my systems with a single disk/SSD I'm BTRFS all the way, because I don't like the additional complexity of managing partitions, especially when btrfs subvolumes gives me most of the controls I actually want
What about installation of new version, keeping home intact? YaST normally would format the system partition and keep /home.
And what exactly is your question?
isn't it clear? :-O Well, doing exactly that on a system with a single BTRFS partition. How do you keep the /home volume intact? Is it supported by YaST? If that is not possible, the recommendation to use two partitions, one for /home, holds. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Vojtěch Zeisek skreiv 17. okt. 2016 14:44:
btrfs is a very good choice for a desktop system, ext4 is no better in
general, that's why btrfs *is* the default choice :-)
May I ask why then /home is proposed with xfs ? ;-) I think because /home has so many quickly changing files it'd produce huge snapshots and fragmentation. It is better to use another tools to backup Your home.
I use BTRFS on /home, and I love it. With hourly snapshots, I never have to worry about accidently deleting or modifying a file. (And yes, it has saved me several times.) I don’t have a problem with huge snapshots or fragmentation. Of course there are many quickly changing files, but they’re usually small, e.g. settings files. But I do (manually) clean up old snapshots from time to time, usually when I’m starting to run low on free disk space. I also do regularly backups to an external hard drive, and the snapshots help there too. I use rsync, but instead of rsyncing the contents of /home, I rsync the contents of the latest snapshot (which is at most an hour old). This means that I don’t get any warnings from rsync about files changing ‘in mid-air’ – I always get a ‘clean’ backup. (And yes, I *am* aware of the ‘btrfs-send’ tool. But it’s more complicated to set up, I still don’t fully trust it (or myself in using it correctly) and rsync (--update) is plenty fast for me.) -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
20.10.2016 19:07, Karl Ove Hufthammer пишет:
I also do regularly backups to an external hard drive, and the snapshots help there too. I use rsync, but instead of rsyncing the contents of /home, I rsync the contents of the latest snapshot (which is at most an hour old). This means that I don’t get any warnings from rsync about files changing ‘in mid-air’ – I always get a ‘clean’ backup.
(And yes, I *am* aware of the ‘btrfs-send’ tool. But it’s more complicated to set up, I still don’t fully trust it (or myself in using it correctly) and rsync (--update) is plenty fast for me.)
One possible optimization is to only transfer changed files since previous snapshot; see as example https://www.tummy.com/blogs/2010/11/01/fun-with-btrfs-what-files-have-change... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/2016 12:37 PM, Andrei Borzenkov wrote:
One possible optimization is to only transfer changed files since previous snapshot; see as example https://www.tummy.com/blogs/2010/11/01/fun-with-btrfs-what-files-have-change...
Well, yes, but there is also inotify https://lwn.net/Articles/604686/ and fschange http://stefan.buettcher.org/cs/fschange/ Heck, that's a LOT more general/comprehensive than what you get with BtrFS! -- How inappropriate to call this planet `Earth' when it is quite clearly `Ocean'. -- Arthur C Clarke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 17, 2016 at 11:49 AM, Michael Hamilton <michael@actrix.gen.nz> wrote:
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Is there any technical document describing the reasons behind having so many subvolumes?
a) SUSE wants to use snapshots of system as safety measure. Snapshots are per-subvolume, you do not want to revert your database when you revert failed kernel update, so applications are placed in own subvolumes. What complicates things, /some/ parts of /var actually belong to the system as a whole (package database is the best example of it) so you cannot simply move whole /var to own subvolume. Probably in the long run filesystem hierarchy needs to be revisited. b) btrfs is not particularly friendly to some workloads like database or VM image. Again, storing such data in separate subvolume provides for disabling offending btrfs features (CoW in the first place) per-subvolume.
Someone else was asking the same question at stackexchange (with no real answers) :
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu...
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
snapper :)
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
Regards, Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17 October 2016 at 13:08, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
b) btrfs is not particularly friendly to some workloads like database or VM image. Again, storing such data in separate subvolume provides for disabling offending btrfs features (CoW in the first place) per-subvolume.
MINOR CORRECTION (ie. I actually agree with most of what you said and the thrust of your argument) You can actually disable CoW on a folder or files within a subvolume - NoCoW is not an attribute of a Subvolume, but an xattr applied to files. If applied to a directory, the attribute is automatically set on all files created in that directory from that point on. In openSUSE, the YaST installer will set NoCoW on certain mountpoints of certain subvolumes, so the effect is exactly as you described above But I just wanted to clear up it's not a Subvolume feature, you can turn CoW off wherever you want :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On lundi, 17 octobre 2016 15.57:06 h CEST Richard Brown wrote:
But I just wanted to clear up it's not a Subvolume feature, you can turn CoW off wherever you want :)
For my sake, putting this attribute, keep the checksuming function ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
17.10.2016 20:22, Bruno Friedmann пишет:
On lundi, 17 octobre 2016 15.57:06 h CEST Richard Brown wrote:
But I just wanted to clear up it's not a Subvolume feature, you can turn CoW off wherever you want :)
For my sake, putting this attribute, keep the checksuming function ?
No. Once CoW is disabled for a file, checksumming for this file is also disabled. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On lundi, 17 octobre 2016 22.49:09 h CEST Andrei Borzenkov wrote:
17.10.2016 20:22, Bruno Friedmann пишет:
On lundi, 17 octobre 2016 15.57:06 h CEST Richard Brown wrote:
But I just wanted to clear up it's not a Subvolume feature, you can turn CoW off wherever you want :)
For my sake, putting this attribute, keep the checksuming function ?
No. Once CoW is disabled for a file, checksumming for this file is also disabled.
ok thank you, then it become less interesting for myself and use case than how things works with luks/lvm and ext4/xfs -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/18/2016 01:31 AM, Bruno Friedmann wrote:
ok thank you, then it become less interesting for myself and use case than how things works with luks/lvm and ext4/xfs
You don't need LUKS to make use of LVM. Encrypting the whole disk is pretty heavy. if you do need encryption than you should look into whether you need to encrypt files, file systems or whole partitions. If, for example, you need to protect keys, ssl keys for example, they generally live in one directory. You can encrypt that and only decrypt when actually needed. Trust me, decrypting a whole disk that has crashed is ... difficult. -- Vizzini: INCONCEIVABLE! Inigo: You keep using that word. I do not think it means what you think it means. -- The Princess Bride -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On mardi, 18 octobre 2016 08.11:44 h CEST Anton Aylward wrote:
On 10/18/2016 01:31 AM, Bruno Friedmann wrote:
ok thank you, then it become less interesting for myself and use case than how things works with luks/lvm and ext4/xfs
You don't need LUKS to make use of LVM. Encrypting the whole disk is pretty heavy. if you do need encryption than you should look into whether you need to encrypt files, file systems or whole partitions.
If, for example, you need to protect keys, ssl keys for example, they generally live in one directory. You can encrypt that and only decrypt when actually needed.
Trust me, decrypting a whole disk that has crashed is ... difficult.
Trust me also the only way to not be catched and then be sorry, is encrypting the whole disk, so no leak at all ;-) With a modern xeon cpu and nvme pci ssd, you can't find real penality. (Was already true with my former laptop) One real big step forward on our openSUSE, will certainly be to have whole encryption disk and btrfs on top without lvm supported by yast. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Bruno: I subscribe to the list, there is no need to CC me. On 10/18/2016 09:53 AM, Bruno Friedmann wrote:
Trust me also the only way to not be catched and then be sorry, is encrypting the whole disk, so no leak at all
Catched at what? There are a whole pile of treats, attacks and vulnerabilities that having the disk encrypted when not in use won't protect against. Most attack trees work when the disk is active, when you are using it, and many invovle "you" rather than the disk. Having an encrypted disk won't help if you're spear phished, if you download malware, if you visit a malicious site and fall prey to some cross-site scripting attack. If I had to rate encrypting a disk while off-line as a security control, I'd rate it of less importance than many other items. Ultimately all it really protects against is someone stealing the disk when you're not using the machine. That's a backstop to physical protection. It might apply, indeed, for a laptop. There are many cases of laptops being stolen in a variety of circumstances. But if we're talking about a home computer or a corporate computer or a machine in a data centre, then there should be physical access controls in place long before anyone gets near the machine. Yes that's easier in a corporate setting, yes offices and home do get broken into. But there are many things more portable to steal than a computer. Yes, there's the scenario where a competitor wants to steal secrets, but most cases I've read about they stole the data by electronic means. Even the "Chinese Nuclear Spies" and Edward Snowden used USB devices rather than opening up computers and taking the hard drives. Ultimately its about Risk Management. No threat ==> No Risk --> no need for a control So back to the original point. What threat in WHAT CONTEXT are you using full disk to protect against? Could this be dealt with by the other means I've suggested? What controls do you have in place to protect against the higher risk thrreats? -- For effective security, risk must be mitigated at all layers of an organization, from physical, application, networking, social engineering etc. Any weakeness in any layer exposes an organization to risk. I do not see how a single solution can touch all layers. -- Lance Spitzner 16/Feb/01 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I make it short, we are diverging for the topic ;-) While all the other points make sense and are in place for getting securing things the best chance to resist to different kind of vectors and add layers On mardi, 18 octobre 2016 10.36:47 h CEST Anton Aylward wrote:
Could this be dealt with by the other means I've suggested?
The full disk encryption is the first layer that allow me to be not worried about a rought steal of the laptop. It allow me to have some database running locally with data that has limited exposure rights. you know better than me, that securing is an infinite job, but the thread should ;-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/18/2016 11:56 AM, Bruno Friedmann wrote:
The full disk encryption is the first layer that allow me to be not worried about a rought steal of the laptop.
LOL! Yes, the theft of a turned off laptop, and there have been many examples of that, including laptops stolen from the cars of high ranking government ministers in many counties, is a valid use-case. You may want, however, to check out a novel by John Stanford that I read two years ago: "The Hanged Man's Song". The plot revolves around a theft of a laptop (and the murder of the owner, a house-bound veteran in a wheelchair, who is also an ace hacker. The theft occurs while the laptop is in use and although the disk in encrypted, because its in use, the files are all accessible. The theft keeps the laptop powered and uses it to blackmail various other people the hacker was in touch with. As with so many 'hacker' novels, many details are overblown, what's possible (given enough time, computing power, social contacts etc) and what's practical are conflated mercilessly. But the basic point is valid: if you're using the laptop then you've entered the encryption key then its accessible. You need another lay of protection -- in the case of Sandford's novel a password protected screen saver would have done the job :-) And lets face it, a password protected screen saver is a de-facto control even for desktops in many settings. I may be the only person in the house, but what if the cat decides to sleep on the keyboard? I don't need an encrypted disk on my home desktop system, and the same applies in many business settings, not least of all to the 'always on' servers. But encrypting backups ... that's a different matter. (Of course that then gets into the conundrum of 'Key Management'.) Of course there are all the standard caveats about protecting encryption keys, in particular this point from my DatabaseOfDotSigQuotes: Over the last few centuries, mathematicians have demonstrated a remarkable tendency to underestimate the cryptanalytic powers of blunt and heavy objects. -- Jamie Reid, CISSP -- Amateurs hack systems, professionals hack people -- Bruce Schneier -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/17/2016 04:49 AM, Michael Hamilton wrote:
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
There are always gainsayers who remember the early, buggy days of any software, be it KDE4, systemd, or BtrFS. I've kept with the kernel_stable and am now at 4.8.2-2.g7574477-default The structure of BtrFS was stabilized some while ago, later than the kernel of the 13.1/2 DVDs. You can't use those for emergency repair now. I use BtrFS for my rootfs. I have a 20G partition that is less than half full. But then my /boot, /usr/share, /opt, /srv, /var and /tmp are separate file systems. I also have snapshotting turned off. I understand all its benefits and I ran with it for a couple of years, but never needed it. For the most part I favour ReiserFS and XFS for a very simple reason. The fixed, preallocated ratio of inodes to data space we have in ext4 is the same pre-provisioning that we had in UNIX V6 of the early 1970s.. Yes, its a faster file system, more robust, has many more features, but its still stuck in that provisioning mode when every other B-tree based FS does dynamic provisioning. And yes that includes BtrFS, which to my mind is its greatest advantage and one that is hardly ever mentioned. That Ext4 is stuck in this 1970s mindset seems incredible to me. I can't call the developers 'stupid', they're not, there very smart and capable people, but they just have this incredible blind spot, perhaps because they are caught up in backward compatibility with Ext2 and Ext3. This isn't to say Ext4 is useless. It makes an excellent FS for the RootFS. The RootFS isn't, shouldn't be, with the kind of partitioning I have, a dynamic FS. Its full of a fairly predictable set of files once you remove /opt, /srv, /var and /tmp. In an ideal setting, an embedded system for example, that could be configured and made RO. (Well some of the config files could be symlinked. (Reality: a lot of /etc *is* symlinked into /var and /usr/share.) A lot of the Leap vs Tumbleweed vs 13.2 in immortal mode depends on your risk tolerance and your ancillary repository. I'm using 13.2 and see Tumbleweed as ho-hum simply because I make user of things like kernel_stable and other repositories to key things like Firefox more up-to-date. For me, Tumbleweed would be a regression. YMMV, but those ancillary repositories for your specific interests - photography is one of mine - are important. Probably more important that BtrFS or Ext4 for your RootFS. I keep telling myself that one day I'll change my BtrFS RootFS to Ext4, but that day never seems to come. The pain is never there. Even on a rainy winter day I have better things to do. Ext4 or BtrFS for your RootFS just isn't worth getting a later over so long as you have /opt, /srv, /var and /tmp as separate FS. And "oh what a coincidence!", on my system those are Ext4. So please don't think that I'm condemning Ext4. -- Together, we can make ourselves a nation that spends more on books than on bombs, more on hospitals than the terrible tools of war, more on decent houses than military aircraft. -- Robert Kennedy March 24, 1968 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (13)
-
Andreas Schwab -
Andrei Borzenkov -
Anton Aylward -
Bruno Friedmann -
Carlos E. R. -
Johannes Kastl -
Johannes Meixner -
Karl Ove Hufthammer -
Michael Hamilton -
Oliver Kurz -
Richard Brown -
Simon Lees -
Vojtěch Zeisek