I had used btrs & snapper on opensuse 42 (forget rev) and it used to lock up. Are people opting for other file formats? Presently I am using ext4 on / and XFS on /home. This is on a dual boot notebook using ssd if that matters.
I doubt any significant bug remains in the BTRFS filesystem itself. There likely remain shortcomings in the wisdom embodied in its configuration and maintenance tools because of its relative youth. These can only come from experience, which has by now been accumulating for a substantial period.
More important is probably how much space BTRFS has to work with. How big is the SSD in that notebook? How much space do you plan to give openSUSE for its root filesystem? Are you going to keep /home on a separate filesystem? If you plan to give root ample space for snapshotting as well as software, there should remain no significant reason to avoid it.
btrfs is great, but requires sound user experience. With Leap 15.1 being rock stable there is no big advantage in having snapshots. My machine has lots of ext4 only:
erlangen:~ # lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 ext4 fad3604b-5a61-4653-8c14-518d850400ba
├─sda2 ext4 Tumbleweed-HDD 3760cc8d-f468-4654-855b-afcd31071075
└─sda4 ext4 Home-HDD f5177cae-4082-44ed-9471-b99030f06866 2T 42% /home-HDD
sdb
├─sdb1 vfat 4A24-B10D
├─sdb2 ext4 ArchLinux 690b51d7-7034-4585-b362-615f8056be45 22.1G 20% /ArchLinux
├─sdb3 ext4 Tumbleweed-SSD 083dd95e-4073-43b1-a213-ad3ed8dd9a33 10.4G 60% /Tumbleweed-SSD
├─sdb4 ext4 Home-SSD f4c5463f-f43d-420a-a0ea-4456cfbc54fa 114.3G 63% /home-SSD
└─sdb5 btrfs d2a744da-8a53-4321-aada-81f97e7f8d63
sdc iso9660 openSUSE_Leap_15.1_KDE_Live 2019-08-01-16-22-40-00
├─sdc1 iso9660 openSUSE_Leap_15.1_KDE_Live 2019-08-01-16-22-40-00 0 100% /run/media/karl/openSUSE_Leap_15.1_KDE_Live
├─sdc2 vfat BOOT 080B-F3FC
└─**sdc3 ext4 cow cec96381-7c8a-4fe1-b809-b5b5c21f645b 54.2G 1% /run/media/karl/cow**
nvme0n1
├─nvme0n1p1 ext4 Fedora 047d4d83-a9a7-482e-8d15-a1c855a637ea
├─nvme0n1p2 ext4 Tumbleweed 8b190950-c141-4351-9198-7a9592b4fb34 10.1G 63% /
├─nvme0n1p3 ext4 Home 704621ef-9b45-4e96-ba7f-1becd3924f08 184.2G 54% /home
└─nvme0n1p4 vfat 6DEC-64F9 84M 16% /boot/efi
erlangen:~ #
For some good reason even the live version of Leap 15.1 uses ext4. 
If you select the default installation, you no longer get a separate /home partition; it is a btrfs sub-volume on the root partition. Whether that is important is up to you.
Now this is interesting. Doing an upgrade, the lack of /home wasn’t an issue since it already existed. Thanks for the heads up. I’m at a loss why this was changed as I always thought the separate /home was a good idea. Worse comes to worse, you can save the personal data even if you can’t boot.
The new SSD will be a 1TB. I found this
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.expert_partitioner.html
Looks like good advice if you want to keep the snapshots small. However I’m thinking of just going ext4 as the other poster indicated. That said, I think I will make /usr/local a separate partition. Once I had to reload the OS and lost what I had compiled. I run my own mail server so the keeping the mail directories off the main partition shouldn’t be needed. Still that link has a lot of things worth considering.
Is it possible to overthink this? Of course not. That is why we run linux.
Doing some searches, the differences between Ext4 and XFS are interesting. I found this on Redhat:
So XFS is a bit CPU intensive. Maybe that is why / should be ext4 and /home be xfs. This notebook uses m.2 ssd, so the I/O speed should not be an issue. (I agonized over two or three bits per cell. I decided to go with two.)
Having been bit once on btrs, I will go your route and avoid the snapshots.
More on xfs vs ext4 from: News zu ftp.fau.de (ftp.uni-erlangen.de) | Changing filesystems: From XFS to EXT4, mirroring http://download.opensuse.org/:
“Apparently, there was a bug in newer XFS versions. So I took the problem to the XFS mailing list. The responses were surprisingly quick and competent: Apparently there are situations where XFS will need large amounts of unfragmented kernel memory, and when such memory is not available, it will essentially block until there is. Which might be “when hell freezes over”. Until then there is no I/O to that filesystem anymore. The suggested workaround of increasing vm.min_free_kbytes and similar settings so the kernel would be more likely to have enough memory immediately available for XFS did not work out, hangs were still happening at an unacceptable rate – a FTP server that is unavailble for 2 times 10 minutes a day isn’t exactly my idea of a reliable service for the public. The XFS developers seemed to have some ideas on how to “do better”, but it would not be simple. I did not want to wait for them to implement something – and even after they did I would still have to run a handpatched kernel all the time, which I was trying to avoid. So a switch of filesystems was in order. That was probably a good idea, because according to a recent post on LKML the situation is still unchanged and no fix has been implemented yet”
So XFS is a bit CPU intensive. Maybe that is why / should be ext4 and /home be xfs. This notebook uses m.2 ssd, so the I/O speed should not be an issue. (I agonized over two or three bits per cell. I decided to go with two.)
I got excellent performance with m.2 SSD/ext4, see: https://forums.opensuse.org/showthread.php/533772-Running-Tumbleweed-on-HP-Laptop-15-da0xxx and i7-6700k vs. i5-8520U: Running jAlbum on Notebooks ... - jAlbum forums
Hi
There is always i/o schedulers to consider as well… I’ve not had issues with btrfs/xfs (I don’t run snapper/snapshots), but do use mq-deadline for my SSD’s and bfq for rotating rust.
Bottom line, use whatever filesystem you feel comfortable with…
IMHO BTRFS is for a servers with an UPS, atomic updates, snapshots, etc.
BTRFS will eat battery of your notebook.
BTRFS can damage data in a drive with a power loss.
Hi
Not seen anything like that here… with either desktop and laptops…
At what rate compared to other file systems?
The SLES documentation has some information about Btrfs and the other options:
https://www.suse.com/documentation/sles-15/book_storage/data/sec_filesystems_major_btrfs.html
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP1/#TechInfo.Filesystems.Comparison
I wouldn’t use Tumbleweed without the ability to rollback, but then you’re using Leap.
After 3 years of using Btrfs, I can’t blame any of my problems on the file system.
Oh on the other hand I can go all ext4.
Some general comments for someone stumbling on this thread. Opensuse has a program called baobab for disk analysis. In my case, I want to put /usr/local on its own partition, so this helps in determining how much space I need to reserve. I currently have about 7G there.
I haven’t done much with docker like programs, but potentially someone who uses that technology a lot might want to consider putting them on a separate partition. I had installed whisper system via flatpak for yucks since there there was no way to compile it at the time.
My advice: Keep it simple and minimal.
rig:~ ▶ sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
└─sda1 ext4 RIG 8xxxx0e0-xxxx-444e-xxxx-1f56ebxxxx4d /
rig:~ ▶ _
Important with SSDs: always keep partition boundaries properly aligned. Check it with the blockdev command:
rig:~ ▶ sudo **blockdev** --getalignoff /dev/sda1 *# should always return zero*
0
rig:~ ▶ man blockdev
With one big ext4 partition I like the way …
- how I can »cp -a« all of sda1 and have complete, instatly readable and instantly bootable backups;
- how even very old rescue media and ancient disk tools recognize ext4 properly;
- how I don’t have to worry about size/contents/integrity of a DOS-FAT-formatted EFI boot partition (because GRUB always boots into the one primary MBR-based ext4 partition);
- how there never are dozens of busy btrfs-snapper/helper/scrubber/you-name-it
tasks using up CPU cycles, energy, megabytes of RAM and SSD write cycles; - how I can still reason about the relatively compact and clean ext4 source code and data structures (some as old and well-documented as ext2) — much harder to do for XFS/btrfs/ZFS etc.; - how all this avoided complexity provides me with an ease of mind, which can be even more important when you work with a fleet of Linux/*BSD servers on a daily basis.
Just my 2¢.
Cheers!
(Edited to fix typo.)
Problem with a single large root partition is that it is more problems to upgrade not having a separate /home
With ext4 30 gig is more then enough space for root and the rest can be set to home. Many can get by with 20 gig.
I keep 2 30 gig partitions and rotate between versions and keep my one large home. Fresh installs are less problematic then upgrades.