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)

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 /@/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

Hello, On Oct 18 10:22 Andreas Schwab wrote (excerpt):

On Okt 18 2016, Johannes Meixner 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

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

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

On 17 October 2016 at 14:44, 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.

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 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

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

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 17 October 2016 at 13:08, Andrei Borzenkov 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

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 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

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

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