dd from Leap-15.3

[bad sector]

I do a lot of dd to back up or restore partitions but lately I've had
to avoid doing so from a Leap-15.3 Konsole. While Slackware's
root login at cLi level has always been the fastest and most
reliable UI to do this from, it also worked from any terminal in
GUI environments but in Leap it lately often results in a totally
locked system. Not so in TW, Slackware, Devuan or Artix.

[Aragorn]

On 26.12.2021 at 17:19, bad sector scribbled:

According to my information — which may be wrong — openSUSE Leap uses
btrfs by default, and if you're used to other filesystems, then btrfs
is a whole other beast.

I'm not so sure whether dd would be the right tool to use with btrfs,
among other things because btrfs aggressively caches and buffers, in
combination with that it uses copy-on-write. And if you're running dd
from a terminal emulator in a graphical environment, then there's a lot
of data being cached and buffered.

--
With respect,
= Aragorn =

[Carlos E.R.]

I have been doing dd from partitions to a file residing on btrfs
(several disks) with compression and encryption, without snapshooting,
and it works fine. However, none using 15.3 yet, and none using plasma
nor KDE.

Now, if you mean that the source partition is formatted as btrfs, that's
irrelevant, because the filesystem has to be umounted.

Now, if you find a situation that crashes the system, you must report it
in Bugzilla.


--
Cheers, Carlos.

[bad sector]

Since the (aleged) demise of Reiserfs I use only ext4 but I "had"
read some time ago that BTRFS was "dd unfriendly". Regardless,
in this case I suspect some segfault or the like. Don't know what
would lead to a lockup and I won't TS either, the only time I cannot
use Slackware cLi for this is when making a backup of Slackware,
I could even do that from a slacker frisby :-)