Not OP, but yes, that’s pretty much how it works. (ZFS scrubs do not defrgment data however).
Fragmentation isn’t really a problem for several reasons.
Some (most?) COW filesystems have mechanisms to mitigate fragmentation. ZFS, for instance, uses a special allocation strategy to minimize fragmentation and can reallocate data during certain operations like resilvering or rebalancing.
ZFS doesn’t even have a traditional defrag command. Because of its design and the way it handles file storage, a typical defrag process is not applicable or even necessary in the same way it is with other traditional filesystems
Btrfs too handles chunk allocation effeciently and generally doesn’t require defragmentation, and although it does have a defrag command, it’s almost never used by anyone, unless you have a special reason to (eg: maybe you have a program that is reading raw sectors of a file, and needs the data to be contiguous).
Fragmentation is only really an issue for spinning disks, however, that is no longer a concern for most spinning disk users because:
Most home users who still have spinning disks use it for archival/long term storage/media that rarely changes (eg: photos, movies, other infrequently accessed data), so fragmentation rarely occurs here and even if it does, it’s not a concern.
Power users typically have a DAS or NAS setup where spinning disks are in a RAID config with striping, so the spread of data across multiple sectors actually has an advantage for averaging out read times (so no file is completely stuck in the slow regions of a disk), but also, any performance loss is also generally negated because a single file can typically be read from two or more drives simultaneously, depending on the redundancy config.
Enterprise users also almost always use a RAID (or similar) setup, so the same as above applies. They also use filesystems like ZFS which employs heavy caching mechanisms, typically backed by SSDs/NVMes, so again, fragmentation isn’t really an issue.
ksmbd is still SMB, except it’s implemented within the Linux kernel. As a result, file transfers speeds are improved greatly compared to pure-Samba which runs only in userspace.
The second thing is, you need to check which SMB protocol you’re using, ideally you’d want to use at least SMB 3, anything older than that will be painfully slow.
Finally, I read in your other comment that you’re using spinning disks and a USB dock. That adds significant overheads.
The Ironwolf drive benchmarks starting at 250MB/s and slows down to 100MB/s as it reaches the end of the drive. (spinning disks gradually become slower the more full it becomes.) Now add file fragmentation + filesystem overheads (buffers, cluster size allocation etc) and the speeds could go down considerably.
Then there’s your SATA > USB dock - no dock would ever reach 5Gbps, that’s just false advertising - it’s only mentioning the theoretical protocol speed. In reality, you’d be seeing something like below 100MB/s write speeds for 128k sequential writes, but if your block size is smaller, expect far slower writes.
Combine all of the above and you can imagine just how much slower this whole thing can be.
For reference, see this benchmark as an example, to see what’s “normal” for a simple file transfer to a blank drive with no fragmentation: www.anandtech.com/show/6014/…/3
I use multiple systems and even I feel NixOS is overkill, especially with their confusing and sometimes incomplete documentation.
On the other hand, Nix the package manager has been fantastic - especially if you’re on an immutable OS, or running some ancient “stable” distro - you can get all the packages you want, without breaking your system - and no need to learn the Nix language and write convoluted config files.
however when I rebase to that image it drops me into rescue mode after reboot. :(
Did you rebase to the unsigned uBlue image first?
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/startingpoint:latest
This will install the proper signing keys and policies and prepare you to rebase to a different signed image. After you run the above command reboot, and then rebase to the actual image you want to rebase to.
Similar experiences here. I remember waiting for the free CDs bundles with monthly magzines, and add then I’d the CD as a mirror in my repos to update my packages lol
You’re thinking of just one extension, one instance. Now repeat this for EVERY single Gnome release, for pretty much all extensions (not just this one), and you can understand my frustration. Which is why I’ve left the Gnome ecosystem.
Also, it’s not like v45 came out of the blue, the beta releases were available for quite a while prior to final release, and even before the final, the Gnome developers did warn that about the upcoming extension changes. So it’s not like the Material Shell devs were unaware.
Edit: Also, the PR may have been merged but the updated version hasn’t been released yet. Both the versions on Github and the Gnome extensions site are still the old release.
Back when I was still on Gnome, I gave this a try and it was great - until Gnome got updated and it stopped working. And then they’d fix it, and Gnome got updated and it stopped working again. So I stopped using it because I couldn’t deal with the constant breakages. I see that they still haven’t updated it for Gnome 45, despite a bug report being opened for it over two months now. It’s exactly because of breakages like this, and extension neglect from the authors, that I’ve stopped using Gnome and switched to KDE.
KDE worked great for me out-of-the-box, so I didn’t install any third-party extensions. The only changes I’ve made is for aesthetics - moved the panel to the top, enabled a global menu and a side dock, for a more Gnome/macOS-style layout.
Ooh, Win 3.11? Which version of Linux did you switch to at the time?
I don’t recall the kernel version, but my first was Red Hat 5.2 in the late 90s. I didn’t switch to Linux permanently though, had it on dual-boot. But eventually it was SuSE that won me over, with their YaST tool and polished KDE implementation - seemed lightyears ahead of Win 9x and ME at the time.
Just use a terminal multiplexer to split your screen (so you don’t need a separate tab), and then ceate an alias/session file with your monitoring programs so you can call it with a single command.
There is a browser extension called “Netflix 1080p”, but in my experience the quality isn’t the same as Netflix’s native 1080p - the quality with the extension is visibly lower (but still better than 720p). And of course, it can’t do 4K at all. It also occasionally breaks, which is annoying.
If you really want to play streaming services at full quality, it’s better to just get a streaming stick like a Fire TV Stick, or a Roku or similar.
I use uBlue and update manually (using a custom alias/script) whenever I get the time, like say during my lunch break or something. Reason being, I actually like watching the update process and seeing what gets updated, watching out for major version number changes or major package upgrades, and if I’m interested I may look up some of their changelogs to find out about their new features etc.
and being forced to reboot
You should be forced to reboot though? And if you don’t want to reboot, can’t you just do an –apply-live? I mean you’d still need to reboot for a kernel update but for the most part, you should be able to use most of your new packages without a reboot. And this holds true even more so if you’re updating Flatpak/container/Nix/pip/cargo/brew packages. And I hope you’re not doing the rookie mistake of actually installing stuff at the ostree layer instead of using Flatpaks/containers/Nix etc.