From Newsgroup: comp.os.linux.misc

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:

On Sat, 26 Sep 2026 19:21:20 -0400, jayjwa wrote:

... I think I'll stick with "dd".

Tips for dd when copying to USB sticks, SD cards, etc:
* Use a larger blocksize (e.g. "bs=65536"). If not specified, the default

Why so small? bs=1M bs=4M bs=8M

Elijah
------
but agreed that the 1/2 kilobyte default block size is unreasonably small
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sun, 27 Sep 2026 04:18:09 -0000 (UTC), Eli the Bearded wrote:

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:

* Use a larger blocksize (e.g. "bs=65536").

Why so small? bs=1M bs=4M bs=8M

I doubt it makes much difference to anything.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 9/26/26 23:00, Lawrence DrCOOliveiro wrote:

On Sat, 26 Sep 2026 19:21:20 -0400, jayjwa wrote:

... I think I'll stick with "dd".

Tips for dd when copying to USB sticks, SD cards, etc:

* Use a larger blocksize (e.g. rCLbs=65536rCY). If not specified, the default
is to read and write 512 bytes at a time, which can be quite slow.
The device does not need to be an exact multiple of this in size; dd
will correctly cope with a partial block at the end.

* Use lsblk to correctly identify the device before writing. Useful
information columns to ask for: name,size,vendor,model,serial.

* IrCOve starting specifying rCLconv=fsyncrCY, just to be sure buffers are
flushed at the end before removing the stick/card. YourCOve probably
been getting away without this before, and so have I, but I think
itrCOs better to be safe than sorry. ;)

Feel free to offer any other tips you have found useful.

Don't really see the POINT in Ventnoy.

Download distro ISOs from the native site, no
middlemen/tampering/spying, and then there are a
number of stick/dvd-burning apps. I like 'Etcher'
but there are more.

'dd' works, but doesn't really do checksums/checks
on what's copied. Had a BAD copy of Kali ... 'dd'
would not say, but Etcher did.

Sad to say, a number of Linux distros won't FIT on
a standard DVD anymore .....

I paid good money for an external DVD/DVD-DL/BR
unit so I *could* burn big stuff. Most have not.

HDDs are pretty good, but still NOT as archival
as DVDs/BRs.

About twice a year I burn a big BR disk with
my Most Important Stuff and stick it in a drawer.
Insurance - even a direct lightning strike or
tornado and it'll still be good.

My last couple years before retiring, was heavily
keen on good BACKUPS. Wrote a number of apps,
mostly Python and Pascal, to do the company stuff
to both local and 'cloud'. Anything that went to
'cloud' was pre-encrypted though, don't TRUST
any of them. Three layers, to a limited extent
four layers. This is what you NEED in the nasty
modern world.

Alas the New Guy - good with M$ solutions though -
could not write a ten-line Python script. This
seems to be the modern standard. It's also what
the new management wanted. Probs ? Not OUR fault !

Pascal ? 'C' ? Forget it. NOT sure he ever even
HEARD of them. But, well, he IS the 'modern IT
guy'.

NOT so good IMHO. But, alas, seems more and
more 'typical'.

I remember programming in 'B' and earlier,
in FORTRAN and COBOL and even a little
PL/I. Had to kind of know them all back
in the day. OK, could not STAND "LISP" ...

Sorry, COBOL, Never Again :-) DID find a
Python 'IDE' for COBOL however, runs
in Linux. Not too bad. SOME make big
money fixing 1960s COBOL biz/govt
programs - nobody can afford to replace
them these days - stuck forever with "What
We KNOW Works". Those old narrow-tie
COBOL/FORTRAN guys were Damned Good !

Just before I retired I wrote a little
format-conversion pgm for some commonly
used data - in FORTRAN. SUFFER motherfuckers,
get WITH the program ! "IT" should MEAN
something :-)

When Vlad/Xi move, the FIRST thing to get trashed
will be everything on M$ and Apple. I envision
this big shiny red button on Xi's desk labeled
"Destroy The West" ........ it'll also get all
the power plants and refineries and chem industries
and comm companies. "BLINK!" - GONE.

Do your bankers Know Your Face ???

Note 'B' and its predecessors CAN be had
for Linux still. Worth fooling around with
just a bit. Know yer past to know yer future.

Never got a PL/I implementation to work
properly alas. Even worse luck with the
Modula-3 stuff - a gazillion weird errs.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-09-27, Lawrence DrCOOliveiro wrote:

On Sun, 27 Sep 2026 04:18:09 -0000 (UTC), Eli the Bearded wrote:

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:

* Use a larger blocksize (e.g. "bs=65536").

Why so small? bs=1M bs=4M bs=8M

I doubt it makes much difference to anything.

I think somebody somewhere compared performance and determined a sweet
spot, but that was, I think, on StackExchange, and all I'd get now
looking for it would be "Enable JavaScript and cookies to
continue"... (or a completely blank page if I enable JavaScript; cookies
aren't disabled at all).
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-09-27 05:00, Lawrence DrCOOliveiro wrote:

On Sat, 26 Sep 2026 19:21:20 -0400, jayjwa wrote:

... I think I'll stick with "dd".

Tips for dd when copying to USB sticks, SD cards, etc:

* Use a larger blocksize (e.g. rCLbs=65536rCY). If not specified, the default
is to read and write 512 bytes at a time, which can be quite slow.
The device does not need to be an exact multiple of this in size; dd
will correctly cope with a partial block at the end.

* Use lsblk to correctly identify the device before writing. Useful
information columns to ask for: name,size,vendor,model,serial.

* IrCOve starting specifying rCLconv=fsyncrCY, just to be sure buffers are
flushed at the end before removing the stick/card. YourCOve probably
been getting away without this before, and so have I, but I think
itrCOs better to be safe than sorry. ;)

Feel free to offer any other tips you have found useful.

dd if=ISO of=DEV bs=16M oflag=direct status=progress

Otherwise, the iso is cached, using a lot of memory and possibly
starving other processes. Probably this happens severely or nothing at
all depending on the combination of RAM size and ISO size.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 27/09/2026 09:17, Nuno Silva wrote:

On 2026-09-27, Lawrence DrCOOliveiro wrote:

On Sun, 27 Sep 2026 04:18:09 -0000 (UTC), Eli the Bearded wrote:

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:

* Use a larger blocksize (e.g. "bs=65536").

Why so small? bs=1M bs=4M bs=8M

I doubt it makes much difference to anything.

I think somebody somewhere compared performance and determined a sweet
spot, but that was, I think, on StackExchange, and all I'd get now
looking for it would be "Enable JavaScript and cookies to
continue"... (or a completely blank page if I enable JavaScript; cookies aren't disabled at all).

IIRC blocksize made a difference on hard disks, with not of lot of caching

But with modern processors and plenty of memory and even an SSD it is
almost pointless.
--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-09-27 13:57, The Natural Philosopher wrote:

On 27/09/2026 09:17, Nuno Silva wrote:

On 2026-09-27, Lawrence DrCOOliveiro wrote:

On Sun, 27 Sep 2026 04:18:09 -0000 (UTC), Eli the Bearded wrote:

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:

* Use a larger blocksize (e.g. "bs=65536").

Why so small? bs=1M bs=4M bs=8M

I doubt it makes much difference to anything.

I think somebody somewhere compared performance and determined a sweet
spot, but that was, I think, on StackExchange, and all I'd get now
looking for it would be "Enable JavaScript and cookies to
continue"... (or a completely blank page if I enable JavaScript; cookies
aren't disabled at all).

IIRC blocksize made a difference on hard disks, with not of lot of caching

But with modern processors and plenty of memory and even an SSD it is
almost pointless.

Experiments contradict you.

I tested writing a big file to hard disk, with the default blocksize and
a big blocksize, and the difference was measurable (dd).
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 27/09/2026 13:23, Carlos E.R. wrote:

On 2026-09-27 13:57, The Natural Philosopher wrote:

IIRC blocksize made a difference on hard disks, with not of lot of
caching

But with modern processors and plenty of memory and even an SSD it is
almost pointless.

Experiments contradict you.

I tested writing a big file to hard disk, with the default blocksize and
a big blocksize, and the difference was measurable (dd).

Which is what I said

"IIRC blocksize made a difference on hard disks, with not of lot of
caching"
--
rCLSome people like to travel by train because it combines the slowness of
a car with the cramped public exposure of rC?an airplane.rCY

Dennis Miller


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-09-27, Carlos E.R. wrote:

On 2026-09-27 09:05, Lawrence DrCOOliveiro wrote:

On Sun, 27 Sep 2026 04:18:09 -0000 (UTC), Eli the Bearded wrote:

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:

* Use a larger blocksize (e.g. "bs=65536").

Why so small? bs=1M bs=4M bs=8M

I doubt it makes much difference to anything.

Fewer split sectors?

Fewer syscalls?
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-09-27 18:41, The Natural Philosopher wrote:

On 27/09/2026 13:23, Carlos E.R. wrote:

On 2026-09-27 13:57, The Natural Philosopher wrote:

IIRC blocksize made a difference on hard disks, with not of lot of
caching

But with modern processors and plenty of memory and even an SSD it is
almost pointless.

Experiments contradict you.

I tested writing a big file to hard disk, with the default blocksize
and a big blocksize, and the difference was measurable (dd).

Which is what I said

"IIRC blocksize made a difference on hard disks, with not of lot of
caching"

Disks have internal caching way bigger than the default blocksize.

cer@Telcontar:~/tmp> time dd if=/dev/zero of=testfile.zero count=52428800 52428800+0 records in
52428800+0 records out
26843545600 bytes (27 GB, 25 GiB) copied, 148,939 s, 180 MB/s

real 2m28,969s
user 0m11,736s
sys 2m17,029s
cer@Telcontar:~/tmp>

cer@Telcontar:~/tmp> time dd if=/dev/zero of=testfile.zero count=6553600 bs=4096
6553600+0 records in
6553600+0 records out
26843545600 bytes (27 GB, 25 GiB) copied, 105,738 s, 254 MB/s

real 1m45,750s
user 0m1,923s
sys 0m34,904s
cer@Telcontar:~/tmp>

cer@Telcontar:~/tmp> time dd if=/dev/zero of=testfile.zero count=409600 bs=65536
409600+0 records in
409600+0 records out
26843545600 bytes (27 GB, 25 GiB) copied, 105,819 s, 254 MB/s

real 1m47,710s
user 0m0,111s
sys 0m21,869s
cer@Telcontar:~/tmp>

cer@Telcontar:~/tmp> time dd if=/dev/zero of=testfile.zero count=25600 bs=1048576
25600+0 records in
25600+0 records out
26843545600 bytes (27 GB, 25 GiB) copied, 106,455 s, 252 MB/s

real 1m48,224s
user 0m0,000s
sys 0m22,769s
cer@Telcontar:~/tmp>
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 9/27/26 06:53, Carlos E.R. wrote:

On 2026-09-27 05:00, Lawrence DrCOOliveiro wrote:

On Sat, 26 Sep 2026 19:21:20 -0400, jayjwa wrote:

... I think I'll stick with "dd".

Tips for dd when copying to USB sticks, SD cards, etc:

* Use a larger blocksize (e.g. rCLbs=65536rCY). If not specified, the default
-a-a is to read and write 512 bytes at a time, which can be quite slow.
-a-a The device does not need to be an exact multiple of this in size; dd
-a-a will correctly cope with a partial block at the end.

* Use lsblk to correctly identify the device before writing. Useful
-a-a information columns to ask for: name,size,vendor,model,serial.

* IrCOve starting specifying rCLconv=fsyncrCY, just to be sure buffers are >> -a-a flushed at the end before removing the stick/card. YourCOve probably
-a-a been getting away without this before, and so have I, but I think
-a-a itrCOs better to be safe than sorry. ;)

Feel free to offer any other tips you have found useful.

dd if=ISO of=DEV bs=16M oflag=direct status=progress

Otherwise, the iso is cached, using a lot of memory and possibly
starving other processes. Probably this happens severely or nothing at
all depending on the combination of RAM size and ISO size.

TOO large a buffer size and it's also hard
to tell WHEN the copy is done unless the
target drive has a blinky light. 'progress'
is helpful there, but does seem to slow down
things just a bit.

512 is VERY old-school. 1M to 8M are maybe the better
modern settings.

I've fooled with 'dd' quite a lot. You DO get speed
increases, but maybe only worthwhile up until around
the 8M mark. HAVE seen comparison charts online.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-09-28 07:37, c186282 wrote:

On 9/27/26 06:53, Carlos E.R. wrote:

On 2026-09-27 05:00, Lawrence DrCOOliveiro wrote:

On Sat, 26 Sep 2026 19:21:20 -0400, jayjwa wrote:

... I think I'll stick with "dd".

Tips for dd when copying to USB sticks, SD cards, etc:

* Use a larger blocksize (e.g. rCLbs=65536rCY). If not specified, the
default
-a-a is to read and write 512 bytes at a time, which can be quite slow.
-a-a The device does not need to be an exact multiple of this in size; dd >>> -a-a will correctly cope with a partial block at the end.

* Use lsblk to correctly identify the device before writing. Useful
-a-a information columns to ask for: name,size,vendor,model,serial.

* IrCOve starting specifying rCLconv=fsyncrCY, just to be sure buffers are >>> -a-a flushed at the end before removing the stick/card. YourCOve probably >>> -a-a been getting away without this before, and so have I, but I think
-a-a itrCOs better to be safe than sorry. ;)

Feel free to offer any other tips you have found useful.

dd if=ISO of=DEV bs=16M oflag=direct status=progress

Otherwise, the iso is cached, using a lot of memory and possibly
starving other processes. Probably this happens severely or nothing at
all depending on the combination of RAM size and ISO size.

-a TOO large a buffer size and it's also hard
-a to tell WHEN the copy is done unless the
-a target drive has a blinky light. 'progress'
-a is helpful there, but does seem to slow down
-a things just a bit.

with oflag=direct that's a non issue.

-a 512 is VERY old-school. 1M to 8M are maybe the better
-a modern settings.

-a I've fooled with 'dd' quite a lot. You DO get speed
-a increases, but maybe only worthwhile up until around
-a the 8M mark. HAVE seen comparison charts online.

--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Le lun. 28 sept. 2026 10:09:16, Carlos E.R. a |-crit:

On 2026-09-28 07:37, c186282 wrote:

[snip]
-a TOO large a buffer size and it's also hard
-a to tell WHEN the copy is done unless the
-a target drive has a blinky light. 'progress'
-a is helpful there, but does seem to slow down
-a things just a bit.

with oflag=direct that's a non issue.

Also with conv=fsync (*not* conv=sync): dd -2 physically write output
file data before finishing -+

time (dd if=/dev/zero of=testfile.zero bs=1M count=8K conv=fsync)
real 0m23,869s
user 0m0,009s
sys 0m2,893s

time (dd if=/dev/zero of=testfile.zero bs=1M count=8K && sync)
real 0m24,358s
user 0m0,002s
sys 0m2,947s
--
Philippe

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Mon, 28 Sep 2026 12:10:13 +0200, Philippe wrote:

Also with conv=fsync (*not* conv=sync): dd -2 physically write output
file data before finishing -+

ThatrCOs what I have started using. And I advise others to do the same!
--- Synchronet 3.22a-Linux NewsLink 1.2