Brainstorming, preparing for new laptop

[DoYouKubuntu]

The CoreBook install on your new laptop is making me drool.

Should that be CoreBoot, GG?

Since I don't even know what that is, can you tell me why it's drool-worthy?

If you leave Ubuntu on then you could install
kubuntu-desktop
or
kde-plasma-desktop
or, IIRC,
plasma-desktop

Yeah...I think I'm getting dissuaded from that idea... So this thread is doing exactly what I hoped it would! I love you guys so much!

[claydoh]

Again, with only one drive, having multiple partitions (more than /efi, / and /home) gains little to nothing - so your all-purpose Repository of Stuffs and Things is on your $HOME, what difference does it make? when you try to access the files from another computer? So you make the exact same same backup, saving /home/me/Data instead of /data. What is the difference? There isn't one
fewer partitions mean fewer places for such things to get messed up.

The KISS principle applies, but in the sense that keeping as many things as simple as is possible, to allow for more complexity elsewhere.

if there are multiple drives, then yes, this makes perfect sense.

[DoYouKubuntu]

Again, with only one drive, having multiple partitions (more than /efi, / and /home) gains little to nothing - so your all-purpose Repository of Stuffs and Things is on your $HOME, what difference does it make? when you try to access the files from another computer? So you make the exact same same backup, saving /home/me/Data instead of /data. What is the difference? There isn't one
fewer partitions mean fewer places for such things to get messed up.

The KISS principle applies, but in the sense that keeping as many things as simple as is possible, to allow for more complexity elsewhere.
if there are multiple drives, then yes, this makes perfect sense.

Part of my reasoning along the way was that users besides myself, using their own computers, could access 'main' computer's /data and do as they pleased in there, without being able to touch or see or muck up my $HOME. I'm the only person regularly using my network now, but I don't really see why I should change what's worked well for many years, and would work well in the future if something changes and there is another user(s). The concept really started with the idea of a file server, a central location where everyone has access to a pool of files, and can use their own local drives for personal stuff.

[DoYouKubuntu]

I'm not very helpful, except that I mentioned using the dd command to make the bootable USB Kubuntu flash drive, as per my how-to:
Building a Kubuntu live USB flash drive installer using dd
https://www.kubuntuforums.net/showth...712#post378712

Silly, you're helpful!

In your excellent 'dd' info, you said:
"(1) This works no matter what was previously on the flash drive (nothing, an MBR, or a GPT)."

So am I correct in thinking the bootable flash drive I currently have 20.04 on would work?

[Snowhog]

Yup. dd aka Disc (content) Destroyer. dd overwrites ANYTHING that is on the destination drive.

[Qqmike]

Yes, as Snowhog says (about dd overwriting anything already on the drive). Now, I like to "zero-out" a used flash drive by using dd to write zeros over the whole flash drive. That is also shown in my how to (one simple dd statement) So if you zero it out, then it contains only zeros, so your 20.04 is totally gone (no remnants remaining at all). Then I write the new Kubuntu iso to that flash drive (using that dd statement in the how to).

[GreyGeek]

Wow, jglen490, stop holding back! Tell us what you really think!

[Qqmike]

I can't get to Page 3 here! Only to Page 2.

[GreyGeek]

....
I'm still open to hearing COMPELLING reasons to dump ext4 in favor of btrfs,
...

I've been using BTRFS since Kubuntu 16.04 and I have never exprienced any lack of performance for my use case. It's a myth that BTRFS is slow. Comparison tests of BTRFS with EXT4 show that while EXT4 is faster in many areas, it's not that much faster than BTRFS that most people or use cases would notice. I've moved 10's of GB of data from one directory to another using Dolphin's drag & drop or copy or move using right mouse options and by the time I lift my finger from the right mouse button the task is done. I never have to wait on my system to do file work.

My biggest Python project contains a collection of ALL the data from ALL 1,290+ files from US weather stations containing weather data from 1890 to the present. I use that data to create tables, plot graphs and make comparisons with global warming claims. During compiling my bottle neck isn't BTRFS, it is my i7 CPU and only 16GB of RAM. It wouldn't be any faster if I were setting on EXT4.

IF you want to use EXT4 then you will have to decide how you are going to partitiion your SSD. How much for boot, efi, root and home? Having installed EXT4 as a rootfs in the past you've played that game several times. Have you guessed perfectly every time, giving each partition no more or less than your forecasted needs? What if your needs change and /home, or /date, if you create it, no longer has enough room? Do you try to recover unused space from / or some other partition, or plug in another drive and mount it as /data2, then parse your data between /home and /data? Or what ever. You get the picture.

With BTRFS you don't have to worry about such concerns. The rootfs on the drive is a reservoir of space that subvolumes can take from when every they need more space, and can return empty extants back to when no longer needed. It is also a space that you can use for other purposes, which are not visible to users. That's where I keep my snapshot subdirectory into which my @ subvolume snapshots go. The only way you'll run out of space is if you fill up your SSD. But, if you do that, you can merely attach another drive of any type to your system and use the "btrfs device add <device> <path>" command to add it to your rootfs. Takes only a minute. Run a balance operation in the background while you continue to use your system without any slowdown.

With BTRFS you can (but you don?t have to):

• join partitions or disks to build one BTRFS-Volume
• split one Subvolume into two or more Subvolumes and mount them separately (space is dynamically shared)
• use software-raid1 with 2 or more disks of different sizes - probably doesn't apply to you unless you add drives.
• use snapshots (if you want) manual or automatic, at boot or at install or at fixed intervals - the new version of TimeShift I now recommend. One click snapshot with incremental backup to a remote system. If you use only @ you don't have to snapshot @home because it doesn't exist.
• verify your filesystem while it is mounted
• use compression allover the filesystem ( zip, zstd, ?), which increases the apparent size of your disk.
• auto-tuning and self-healing

Kubutu's install creates the root (@) and home (@home) subvolumes and in fstab they are mounted to / and /home. You can leave them that way or do what I did and that was to copy @home/jerry into @/home/ and then comment out the stanza in fstab that mounted @home to /home. Then delete @home to recover that space. Now, I take only one snapshot a day, just before I shut down, OR, just before I do something that could be problematic, like a 350 package upgrade, or installing winehq, or 3Gb of some simulation, etc.

In 5 years of using BTRFS I've had zero problems except those of my own making, and recovering from them was a piece of cake because of the power of BTRFS. I will NEVER use a distro that does not offer BTRFS as the rootfs. Every night I pop open a Konsole and issue: "sudo /mak" and hit tab. It completes the command to run the "make-snapshot.sh" script. I just did it after typing "sudo /mak" above. While the script ran I finished the sentence above. When I popped open the Konsole the snapshot and incremental backup to my second SSD was done. Probably 15 seconds, or less, total.

$ sudo /make_snapshot.sh
[sudo] password for jerry:
Mounting drives
Making today's snapshot
Create a readonly snapshot of '/mnt/@' in '/mnt/snapshots/@202110122128'
Finding previous snapshot as parent
Attempting incremental backup
btrfs send -p /mnt/snapshots/@202110112054 /mnt/snapshots/@202110122128 | btrfs receive /backup
At subvol /mnt/snapshots/@202110122128
At snapshot @202110122128
Delete subvolume (commit): '/mnt/snapshots/@202110081922'
Delete subvolume (commit): '/backup/@202110071853'
Snapshots completed, oldest snapshots deleted
3 syncs done and drives unmounted

Unless you are running a server you will never notice the speed difference between a laptop using EXT4 and one using BTRFS except that making backups are usually a lot faster with BTRFS because of COW. I installed the new TimeShift to try it out on my system, after I made a snapshot, of course. It took 6 minutes to make an rsync backup of my system. I tried out the TimeShift BTRFS option. Worked fast and neat. Everything was done with the GUI, including a rollback. If you do a rollback you reboot immediately after do it. Frankly, I don't worry about BTRFS. FSTRIM is done as a systemd cron job once a week. My primary SSD a 500Gb Samsung EVO 860, has 528 days 10 hours of power on time, 28TB of Lifetime writes and an estimated 1,000 days of life left. It's lasted longer than any spinning disk I've had in this Acer Aspire V3-771G, 9 year old laptop. My second EVO has 328 days power on time, with over 1,000 days of life left. Cavat emptor applies.

Facebook uses BTRFS on millions of its servers and is pleased with both its stability and performance. BTRFS is also the primary file system on FB's workstations. Their top IT engineer gave a talk about it on YT, and he said they build about 100,000 servers and workstations a year out of the cheapest parts they can find and rely on BTRFS to keep the data secure. They couldn't do that with EXT4.

[jglen490]

Wow, jglen490, stop holding back! Tell us what you really think!

Yeah, I guess I should have been a bit more clear and concise as to what I was talking about

In my opinion, BTRFS brings in false concepts for certain use cases that result in an irrational reliance on the file system for long term reliability and recoverability. For instance, writing recovery data "next to" changed files. Since the data written is simply the stuff that changed so that it can be immediately reapplied to recover a changed file back to it's former state, that data is not useful as backup (recoverability) solution. As that data also resides on the drive to which the file applies, in the even of drive failure (reliability) that data is no longer useful.

BTRFS IS useful in an enterprise environment where whole system management concepts are applied for recoverability, reliablity, and the rest of the "*ilities". That is not typical of the single user, small system environment that most of us are engaged in. The BTRFS recovery data, unless rigorously managed, simply collects in the filesystem and eventually eats space that can be used for other purposes. It's the same problem that users were (and probably still are) encountering with solutions like Timeshift that show up unexpectedly as "filesystem full" errors.

That's why I say never rely on a backup, or what you may think is a backup, solution that uses the same filesystem as the data being protected by backup. Also, while each filesystem CAN have it's own foibles and complications, never introduce a system of processes that bring along unneeded or unknown complications.

Hence, BTRFS is unnecessary for the typical single user, small system Linux. No matter how many JPEGs, MP3s, and MP4s you may have on your multi-TB drive. BTRFS has its place, XFS has its place, and ext4 has its place.

[DoYouKubuntu]

GG, thank you so much for your very informative post about ext4 vs btrfs. It does indeed contain interesting info--but not compelling enough for me to switch!

In 35 years, I've never underestimated the sizes of the partitions. But that's only because of actual usage experience. I've learned what percentage I need for each partition, and proceeded accordingly. I've never had the need to go back and resize anything--unless you count the [miserable] days when I had to have windows running at home (for compatibility with some work software that used a dongle), so I had one computer that dual-booted. I remember having to fiddle with its disks a lot before finally getting everything right. Back then (I don't know how it is this millennium) it was super-important the order in which the OSes were installed, and where they existed on the drive(s). Was it fdisk I would've used back then? Whatever, I'm glad those days are long gone.

One other point I've completely forgotten to mention regarding my partitioning scheme: by having all media and important files stored on /data, if I want to do a fresh, clean install/upgrade of K, I can do the install, including formatting / and /home, without worrying about losing anything but the few files stored in $HOME. And, of course, everything is thoroughly backed up before I start formatting!

[jglen490]

That's the same reason that I keep /home on a separate partition from /.

On a fresh install, I format / and keep the ESP and /home. Then the install doesn't touch /home except to update any configs that may occur during the install and to link the mail folders to the Thunderbird installation. But if it works doing what you do, then keep doing it

[DoYouKubuntu]

Yeah, it does work, and it's familiar/comfortable, so I'll stick with it.

I know my OP covered a BROAD spectrum of questions/issues, so not everything has been addressed yet. Let's use Dolphin as an example. Can anyone clue me in on what files I need to save so that my highly-customized Dolphin retains its settings? As noted earlier, in the past, when I used Dolphin's settings/configuration files found in $HOME, only *some* of its settings came through on the new install; others I had to manually rebuild. It's definitely not the end of the world if I have to re-do every app by hand--there are only a few of them, after all--but it would be nice to know which configuration files actually contain all the info for the settings.

[GreyGeek]

Not compelling, huh?

(That's why I gave up preaching! I couldn't convince anyone of anything)


BTRFS dosn't prevent you from saving a snapshot to an external storage device. I took out my CDROM and in its place put an HDCADDY, which contains my 3rd SSD, a 1TB Crucial. I use my 2nd SSD, also an 500GB EVO 860, to store my incremental backups on, which take all of a few seconds if I haven't made many changes to my system since the last incremental backup. For remote storage I plug in one of several USB HDCaddys and do an incremental backup to which ever one I plug in. That can take 5 minutes if the previous snapshot was a week or two old, but I continue with what I'm doing while it works in the background, and I experience no slow down. One or more of those USB Caddy's will go with me in the event of an emergency evacuation of the apartment. But, that remote storage could have just as easily been a cloud server.

What amazes me is folks who use EXT4 and don't keep regular backups using TimeShift or some other method. They break an application, or something happens during an install, and they spend 2, 3, 4 or more hours, or even days trying to recover their system, all the while talking about doing a re-install if their repair work fails. This is insanity. IF they used a reliable backup plan they could have restored their system to its previous prestine condition in under 30 minutes for either BTRFS or what ever rsync plan is used. And what do they do after they reinstall, all the while blaming the distro for their past problems? Nothing, and still expecting a different outcome the next time they fumble the ball. Sometimes it reminds me of the old joke:

[DoYouKubuntu]

Not compelling, huh?

(That's why I gave up preaching! I couldn't convince anyone of anything)

I'm sorry, GG!! I didn't mean to bring you to tears. You know I love you....but I'm sticking with ext4!

BTRFS dosn't prevent you from saving a snapshot to an external storage device. I took out my CDROM and in its place put an HDCADDY, which contains my 3rd SSD, a 1TB Crucial. I use my 2nd SSD, also an 500GB EVO 860, to store my incremental backups on, which take all of a few seconds if I haven't made many changes to my system since the last incremental backup. For remote storage I plug in one of several USB HDCaddys and do an incremental backup to which ever one I plug in. That can take 5 minutes if the previous snapshot was a week or two old, but I continue with what I'm doing while it works in the background, and I experience no slow down. One or more of those USB Caddy's will go with me in the event of an emergency evacuation of the apartment. But, that remote storage could have just as easily been a cloud server.

What amazes me is folks who use EXT4 and don't keep regular backups using TimeShift or some other method. They break an application, or something happens during an install, and they spend 2, 3, 4 or more hours, or even days trying to recover their system, all the while talking about doing a re-install if their repair work fails. This is insanity. IF they used a reliable backup plan they could have restored their system to its previous prestine condition in under 30 minutes for either BTRFS or what ever rsync plan is used. And what do they do after they reinstall, all the while blaming the distro for their past problems? Nothing, and still expecting a different outcome the next time they fumble the ball. Sometimes it reminds me of the old joke:

Oh my goodness, that video cracked me up! It reminded me of a conversation I had with my boss (the owner of the company) one day. I was at home (I started telecommuting in the 1980s--LONG before anyone ever heard of COVID-19) and she'd called with a question. This was in the mid-to-late '90s, and she was using windows. I said "click on 'my computer' and then..." and she said, "you want me to go unlock your office? Which computer should I use?" and I said "no, not *MY* computers, *YOUR* computer, the computer you're looking at right now, click the little icon that SAYS 'my computer'" It went on like an Abbott and Costello routine for I don't know how long. Meanwhile, I had work to do and just wanted to get her off the phone! It sounds funny now, but I assure you I was not laughing at the time. *SMH*

Regarding backups: I used to do incremental backups, both at home and work. But at some point I changed my way of backing up and have stuck with it. I simply copy files/directories, i.e., I don't use any sort of backup command/software/program/etc. Local backups using this method take seconds to minutes, depending on what I'm backing up. But by using this method, restoring files is a simple matter of copying them back! I am thinking about taking a system snapshot after I've tweaked the upcoming new laptop to my satisfaction. That way I can feel free to muck around all I want with its look and feel, knowing that if I hopelessly mess it up I can easily restore what I was happy with.

Oh, that video also reminded of the 'any key' joke that went around the Internet many years ago. Remember? A tech tells the customer to "press any key" and the customer says there is no key like that on their keyboard......