I have a laptop with a small ssd drive and would like to install tumbleweed but with ext4 instead of btrfs and timeshift for the “snapshots” to a large external usb drive (4tb).
The problem is that since the ssd is small on 256gb, the root partition is only 24gb and the snapshots/subvolumes will quickly crash the root partition.
I’ve googled (startpage.com) around and not found and write-ups on how to set rsync/timeshift for tumbleweed with ext4.
Any suggestion?
Thanks
Hi
Disable snapshots and use btrfs (that’s what I have here, but 60GB / with 18GB allocated)? If want to use ext4, then during install use the expert partitioner option to configure as required with partition sizes and file system to use in the dropdowns.
I have used the expert partitioner before with leap. My question (not expressed clearly) is:
After I finish my install, do I just install timeshift & run it before doing the zypper -dup?
That way, I could rollback if there’s a major problem that affects me?
Thanks
Timeshift is not the same as snapper. Time shift is a backup scheme, snapper is a sort of like a dif and not a full backup. There are definite differences.
Why not go with the default install with btrfs using the entire disk? Then you won’t have to worry about snapshots using too much space. You can use rsync, rsnapshot, restic, etc. to back up what you want.
Use the expert partitioner to make the sizes you wish, or partition in advance, selecting only what to mount where and whether and how to partition in the openSUSE installer. Make / at least 40GB, better 50 or 60 if you’re going to stick with BTRFS for /.
This is a bad idea, in my opinion of course! Host 6700K boots into Tumbleweed, which sits on a Crucial SSD, model: CT250MX500SSD1, size: 232.89 GiB:
**6700K:~ #** fdisk -l /dev/sdb
**Disk /dev/sdb: 232.89 GiB, 250059350016 bytes, 488397168 sectors**
Disk model: CT250MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3B04C452-DAD9-45C6-9BD3-AE398288F628
**Device **** Start**** End**** Sectors**** Size****Type**
**/dev/sdb1 2048 1026047 1024000 500M EFI System **
**/dev/sdb2 1026048 283596799 282570752 134.7G Linux filesystem
**/dev/sdb3 283596800 385996799 102400000 48.8G Linux filesystem
/dev/sdb4 385996800 386029567 32768 16M Microsoft reserved
/dev/sdb5 386029568 488396799 102367232 48.8G Microsoft basic data
**6700K:~ #**
**6700K:~ #** cat /etc/fstab
UUID=6B6D-1CDE /boot/efi vfat utf8 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c / btrfs defaults 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /.snapshots btrfs subvol=/@/.snapshots 0 0
# exempted from snapshotting
UUID=227128c2-8703-4859-a006-30dccf5b299c /var btrfs subvol=/@/var 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /usr/local btrfs subvol=/@/usr/local 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /srv btrfs subvol=/@/srv 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /root btrfs subvol=/@/root 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /opt btrfs subvol=/@/opt 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /home btrfs subvol=/@/home 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=227128c2-8703-4859-a006-30dccf5b299c /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
# other
UUID=e5a9c3b6-fbaa-4398-9814-5b531ef10944 /backup-home btrfs defaults 0 0
**6700K:~ #**
**6700K:~ #** btrfs filesystem usage -T /
Overall:
** Device size: 134.74GiB
Device allocated: 54.04GiB
Device unallocated: 80.70GiB **
Device missing: 0.00B
Used: 43.12GiB
Free (estimated): 90.72GiB (min: 90.72GiB)
Free (statfs, df): 90.72GiB
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 96.19MiB (used: 0.00B)
Multiple profiles: no
Data Metadata System
Id Path single single single Unallocated
-- --------- -------- -------- -------- -----------
1 /dev/sdb2 52.01GiB 2.00GiB 32.00MiB 80.70GiB
-- --------- -------- -------- -------- -----------
Total 52.01GiB 2.00GiB 32.00MiB 80.70GiB
Used 41.99GiB 1.13GiB 16.00KiB
**6700K:~ #**
Actually 6700K is a triple boot system with Leap on /dev/sdb3 and Windows 10 on /dev/sdb4 and /dev/sdb5. Backups of /home rely on btrfs “subvolume snapshot” and “send” commands.
Any suggestion?
Stick to btrfs. Use a single partition occupying the whole space available.
Main thing bad about all on one partition is that it can be difficult to change distros and some times upgrade with /home being sub partition on root partition. having separate /home and swap is more flexible then putting all eggs in one basket. 
I disagree.
**erlangen:~ #** grep /@/home /etc/fstab
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /home btrfs subvol=**/@/home** 0 0
**erlangen:~ #**
**erlangen:~ #** fdisk -l /dev/nvme0n1
**Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors**
Disk model: Samsung SSD 970 EVO Plus 2TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F5B232D0-7A67-461D-8E7D-B86A5B4C6C10
**Device **** Start**** End**** Sectors**** Size****Type**
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 3804628991 3803578368 1.8T Linux filesystem
/dev/nvme0n1p3 3804628992 3907029134 102400143 48.8G Linux filesystem
**erlangen:~ #**
Deleting /dev/nvme0n1p3 and expanding /dev/nvme0n1p2 can be performed without rebooting.
BTW: All of these execute as fast as running command ‘pwd’:
[FONT=monospace]**erlangen:~ #** df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 1.8T 412G 1.4T 23% /
**erlangen:~ #** btrfs filesystem resize -1T /
Resize device id 1 (/dev/nvme0n1p2) from 1.77TiB to 789.69GiB
**erlangen:~ #** df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 790G 412G 377G 53% /
**erlangen:~ #** btrfs filesystem resize +1T /
Resize device id 1 (/dev/nvme0n1p2) from 789.69GiB to 1.77TiB
**erlangen:~ #** df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 1.8T 412G 1.4T 23% /
**erlangen:~ #**
[/FONT]
btrfs can be different versions and thus may not be exactly stable. I prefer not to trust it across distros Have not understood the love affair with BTRFS it has little or no advantage in speed It seems to be a swiss army knife does everything but not all that well.
In any case you don’t have to use BTRFS even though it is default.
Snapper is not a backup but is a good idea for things like tumbleweed or if you are a system developer where things may occasionally need restored to previous state.
Created ext4 on the fly and ran recommended Ars Technica fio tests: https://forums.opensuse.org/showthread.php/565294-How-fast-are-your-disks-Find-out-with-fio
block size, btrfs, ext4
4k: 624MiB/s, bw=844MiB/s
64k: 2144MiB/s, 1758MiB/s
1m: 1570MiB/s, 1432MiB/s
It’s not a love affair. It’s common sense.
Strange every test I found on the web says it is more or less a tossup.
Anything can happen, even when benchmarking:
write performance:
block size, btrfs, ext4
4k: 624MiB/s, bw=844MiB/s
64k: 2144MiB/s, 1758MiB/s
1m: 1570MiB/s, 1432MiB/s
read performance:
block size, btrfs, ext4
4k: 41.2MiB/s, 43.3MiB/s
64k: 3044MiB/s, 3025MiB/s
1m: 1783MiB/s, 1894MiB/s
From Ars Technica:
Learning to use fio means really learning the difference between asynchronous and synchronous writes and knowing for absolute certain what it’s going to do at a very low level on an individual argument basis. You can’t be as certain of what tools like HD Tune Pro are actually doing under the hood—and having to deal with different tools on different operating systems means it’s more difficult to directly compare and contrast results as well.
At phoronix.com openSUSE gets low disk results because of using BTRFS by default (which is copy-on-write).
The above results for btrfs are no-copy-on-write.
write performance:
block size, btrfs, ext4
4k: 624MiB/s, 844MiB/s
64k: 2144MiB/s, 1758MiB/s
1m: ** 1570MiB/s**, 1432MiB/s
Btrfs is faster than ext4 except for block size 4k. Read performance for block size 4k is abysmal for both btrfs and ext4. What makes btrfs really great for the openSUSE default data model is its flexibility and fine grained controllability. One partition suffices for virtually every task:
**erlangen:~ #** lsblk -f /dev/nvme0n1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT32 19CF-0B54 510.4M 0% /boot/efi
├─nvme0n1p2 btrfs 0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 1.3T 25% /var
│ /usr/local
│ /srv
│ /root
│ /opt
│ /home
│ /boot/grub2/x86_64-efi
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
**erlangen:~ #**
**erlangen:~ #** btrfs filesystem usage -T /
Overall:
Device size: 1.72TiB
Device allocated: 465.07GiB
Device unallocated: 1.27TiB
Device missing: 0.00B
Used: 449.29GiB
Free (estimated): 1.28TiB (min: 664.14GiB)
Free (statfs, df): 1.28TiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data Metadata System
Id Path single DUP DUP Unallocated
-- -------------- --------- -------- -------- -----------
1 /dev/nvme0n1p2 459.01GiB 6.00GiB 64.00MiB 1.27TiB
-- -------------- --------- -------- -------- -----------
Total 459.01GiB 3.00GiB 32.00MiB 1.27TiB
Used 444.77GiB 2.26GiB 80.00KiB
**erlangen:~ #**
You can do this with ext4 as well - do it all the time on VMware.
Tested with a real partition. Gparted doesn’t agree on this. When mounted it says: Minimum size 50000 MB, Maximum size 50000 MB. When unmounted it says: Minimum size 447 MB, Maximum size 50000 MB. With btrfs resizing works. Experience since 1995 told me traditional bios, dos partitioning and ext file systems are PITA. UEFI, gpt and btrfs are great.
There is no difference between a virtual and “a real partition” when it come to resizing.
Modify the partitions with fdisk or parted, partprobe/kpartx it like you have to do with btrfs and then resize with growpart and finalize with resize2fs.
Works just fine with for example ext4 or xfs, it doesn’t really matter.
The real ext partitions I reduced in size had many non contiguous chunks allocated which required packing of the chunks. This couldn’t be done when mounted. It was always a tedious procedure. Btrfs always allocates contiguous chunks.
i won’t spend more time on discussing drawbacks of ext4 than I spend on maintaining the existing btrfs partitions.