My reasoning here is this: If you’re an inexperienced user who’s going for openSUSE because it’s a quality and user-friendly distro, you’re going to use the defaults when you don’t know otherwise as you trust the installer knows what’s best. If you’re an advanced user or corporation, and thus need features like snapshotting explicitly, you’re expected to be technically experienced enough to know what btrfs is and how to tick the “snapshots” checkbox. Defaulting to the safer ext4 thus makes most sense to me.
I assume SLE (IIRC the more formal and commercial version of SUSE for enterprises) has its own installer with different settings. For it snapshots as a default make more sense. Though at the same time they don’t, as seeing how unstable both btrfs and snapper are I assume it’s a matter of time until some company is going to eventually sue the SUSE team for losing their data due to an accident similar to mine.
I know btrfs has been in development for many years, which is one reason why I trusted that nothing could go wrong. I was surprised too, but only 3 days of using it proved me that it’s both too performance costly and can easily become corrupted.
I’m sure the same behavior exists with both Leap and Tumbleweed. Leap 15 is the latest version which I believe is only a few months behind TW. Thus I don’t think a lot of things have changed and the upgrade wasn’t that heavy.
Hi
Just to be clear, your issue is with snapper, not the btrfs filesystem, your upgrade method seems to me to be an edge case, I’ve been running btrfs for many years now and the only real problems I had with it’s introduction was the number of snapshots kept, which was an easy fix by changing the configuration file.
I’ll be upgrading my SLED 12 SP3 system soon, which will be it’s third SP migration, this system has a 60GB OCZ SSD, I don’t expect any issues…
From what I could tell, snapper was responsible for the high resource usage, however btrfs breakage is what caused the machine to stop booting entirely. Sadly that blurry photo is all I could capture of the errors before I had to reinstall, so it’s not easy to analyze exactly what was blocking it after things broke.
Personally I have had no issues with either btrfs or snapper after I increased the size of the btrfs partition from the recommended size to 224 GB on my intel ssd. It has been a while but I believe the install went with a 40GB partion, which was too small for snapshots.
Over the years (my first hard drive was a 20 MB Seagate added to an PC XT compatible circa 1989) I have experieced failure to boot after a hard reset only once and that was on a Windows machine (Vista or 7). But if you have to do a hard reset you should delay doing it as long as unreasonably possible and cross your fingers. The weakness is not the disk format type, it is interrupting the writing of data to the disk at an unfortunate time.
Using different flavours of Linux over the last 15+ years I have been burned several times after updates that had me looking for boot disks and google to recover without reinstalling, and not always successfully. With Tumbleweed I have also had a few of those situations, but so far btrfs and snapper have always saved the day.
This is rather long winded but I wanted to explain why I disagree wth the title of this topic, particularly with Tumbleweed which can experience as many as 5 updates a week.