On 08/05/2021 20.49, Larry Len Rainey wrote:

Why not have an option for novice that does choice of UEFI or Legacy install with ext4 full root and swap of ram size - now you don't have to worry about size and btrfs problems for novices users - that is better until they can comprehend btrfs and other file system types and partitions.

That would be my choice, but is not what the people that doit chose.

That is how I install every OpenSUSE for users - no btrfs - instead I provide an external 2gb drive and scripts to backup and restore the drives. I also provide a bootable  usb drive with a saved blkid of the system and a script to make all the file systems needed and to restore the last full backup on the external drive so that the restore script can put everything back where it was before the "disaster".

Few users understand enough "linux or windows" to know what they are doing. You have to make it idiot proof. Like the sign over the testing room at Microsoft in 1982 said - "We try to make our Software Idiot Proof" someone with magic marker wrote below it "But the Idiots keep getting smarter".

Right now I have over 100 users doing this all over the world. All using english for the install but some have changed to their native keyboards

(france and turkey). All were ready to go back to Windows after trying Linux until I reinstalled an easy to support version.

Btrfs is not novice friendly and should be a choice for those that understand snapshots - I bet half the people with btrfs do not know how

to rollback a problem.

I have known novices rolling back the system when I did not know about it.

My 2 cents - Unix since 1973, Linux since 1995.

-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

The user (retired) is long in experience as a world authority on Mainframe hardware and Mainframe OS's development including UTS (Amdahl Mainframe Unix) and more than capable to spot the problem. If deleting snapshots didn't fix it his next move was btrfsck. Even years of experience don't shield you from the odd road block or embarrassment. The process certainly needs more thought than it did back in 2004 when I installed openSUSE for a 66 year old retired bus driver and a 77 year old retired welder who had never used a keyboard and had to be told what the backspace and space bar did. Those guys were able to do online updates and add cameras, printers, burn CD's, etc., email and all normal stuff  completely unaided. Regards Sid. On 08/05/2021 19:49, Larry Len Rainey wrote:

Why not have an option for novice that does choice of UEFI or Legacy install with ext4 full root and swap of ram size - now you don't have to worry about size and btrfs problems for novices users - that is better until they can comprehend btrfs and other file system types and partitions.

That is how I install every OpenSUSE for users - no btrfs - instead I provide an external 2gb drive and scripts to backup and restore the drives. I also provide a bootable usb drive with a saved blkid of the system and a script to make all the file systems needed and to restore the last full backup on the external drive so that the restore script can put everything back where it was before the "disaster".

Few users understand enough "linux or windows" to know what they are doing. You have to make it idiot proof. Like the sign over the testing room at Microsoft in 1982 said - "We try to make our Software Idiot Proof" someone with magic marker wrote below it "But the Idiots keep getting smarter".

Right now I have over 100 users doing this all over the world. All using english for the install but some have changed to their native keyboards (france and turkey). All were ready to go back to Windows after trying Linux until I reinstalled an easy to support version.

Btrfs is not novice friendly and should be a choice for those that understand snapshots - I bet half the people with btrfs do not know how to rollback a problem.

My 2 cents - Unix since 1973, Linux since 1995.

On 5/8/21 1:24 PM, Carlos E. R. wrote:

...

On 08/05/2021 17.37, Sid Boyce wrote:

...

Users response.

Regards

Sid.

-------- Forwarded Message -------- Subject:     Re: Fwd: snapshots filling up SSD Date:     Sat, 8 May 2021 15:29:09 +0000 From:     Sav. Mellor <> To:     Sid Boyce <>

SSD are partitioned the same as normal disks, there is no difference. You could leave some space outside of any partition for wear levelling.

-- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks

On 09/05/2021 09:49, Axel Braun wrote:

Am Sonntag, 9. Mai 2021, 00:56:58 CEST schrieb Sid Boyce:

...

The user (retired) is long in experience as a world authority on Mainframe hardware and Mainframe OS's development including UTS (Amdahl Mainframe Unix) and more than capable to spot the problem. If deleting snapshots didn't fix it his next move was btrfsck. Another thing that come to my mind is to check the content of /.snapshot I was hit (in the early btrfs days) by an orphaned snapshot which used an incredible amount of disk space. Deleting this /.snapshots/<number> which was not shown under 'snapper list' fixed the problem. No issues ever since then with btrfs

Cheers Axel

Thanks Axel, That's exactly what I had to do last year when I saw the problem on one of my systems. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks

On Sun, May 9, 2021 at 2:08 PM Carlos E. R. wrote:

On 09/05/2021 18.43, peter.clark@ngic.com wrote:

...

Regarding btrfs-related defaults for SSD, I opened Bug 1184904 for /etc/sysconfig/btrfsmaintenance defaults.

That particular bug is primarily targeting the filesystem corruption seen downstream - probably while live migrating VMs while a balance is running. Setting that value to "none" has stabilized our downstream VMs. Since making that setting, no additional systems have been lost to corrupted btrfs filesystems.

Since btrfs balance rewrites a lot of data apparently without much if any benefit on a single disk non-RAID installation, I also like keeping it disabled to reduce wear on SSDs.

For the use case of the pet Tumbleweeed VM that runs on my personal laptop, I have it set up an f2fs root filesystem. It's an old Macbook Pro with HDD, so I have the VM running on USB flash (at the under $20 price point, I'm assuming there is no wear leveling)

I remember reading somewhere that btrfs was flash aware, but looking at "man mount" I see no references to this. There is some mention on "man mkfs.btrfs"

It happens automatically, but the mount option "ssd" can be used to force it on. -- 真実はいつも一つ！/ Always, there's only one truth!

I took a look at a few VMs that are still on btrfs - Most of them have the 'ssd' flag set when looking at /etc/mtab, even going back to SLES 12, despite not having it specified in /etc/fstab anywhere. The ones that go read-only whenever a btrfs balance runs and need the root filesystem to be restored from backup each time are not showing the ssd flag in /etc/fstab. The backing storage is "all-flash arrays", some of which have NVRAM as the first stage before data written to them is deduplicated, compressed and written to SSD. A similar issue was also seen on a SLES 11 physical system with HDD using hardware RAID, so while lack of the ssd flag might be inducing extra wear on the all-flash arrays, the corruption induced by btrfs balance appears to be independent of that option. That SLES 11 system was aging, however, so it's possible that its hdds were beginning to have timeouts, though.