On 06/09/2024 14:53, Thomas Schmitt wrote:
i wrote:
I let xorriso-dd-target use
bs=1M oflag=dsync
Max Nikulin wrote:
May too small bs value cause write multiplication if internal flash erasure
block size is much larger? [...] My concern is wearing,
Is there evidence that sync size a smaller than such an internal size
is harmful ?
It is no more than my guess. My expectation that some flash firmware may
respect explicit syncs.
Sequential writing by dd would well fit into such a caching strategy.
...unless explicit syncs force writing received data. Sequential writing
with frequent syncs should not be an issue (besides some buggy devices)
if the drive has been fully erased in advance. I am unaware how to erase
a USB pendrive or a SD card. Perhaps some vendors provide special tools.
My hypothesis is that writing to 8MiB erase block in 1MiB chunks over
old data may result in
- erasure or next free segment
- write 0 new data, 1-7 old data
- erasure or next free segment
- write 0-1 new data, 2-7 old data
...
- erasure or next free segment
- write 0-6 new data, 7 old data
- erasure or next free segment
- write 0-7 new data
Of course, firmware may react on syncs in a different way.
Max Nikulin wrote:
I have no idea if firmware may perform
partial overwrites without apparent impact on speed.
Is there evidence ?
No.
I know from own experiments that very small sizes like bs=512 cause slow
copying with and without oflag=dsync. Also very large sizes yielded less
throughput than bs=1M. (My sample set of USB sticks used is small.)
I have only a few USB sticks and SD cards as well and I use some of them
for backup, some are rather old. That is why I asking questions rather
than making statements.
Are there confirmed cases when dd with fixed bs works faster (or more
reliable) than cp built-in strategy? Of course, it better to have some
evidence that dd bs=1M may cause negative impact as well.
Due to my preference to non-destructive way of making bootable media, I
unlikely will be a source of data points. I noticed that people were
arguing concerning oflag=sync so I expected that they may provide more info.
From my point of view, simple cp suggested by the install guide
is quite reasonable in comparison to dd.
cp is not suitable for erasing the last block of the USB stick where the
header of the backup GPT may reside, if the stick was GPT partitioned.
It is a perfectly valid case of dd usage. However I do not expect that
many users have GPT partition table on USB pendrives, so cp should be
suitable for the install guide. On the other hand, some may forget about
their experiments, so the additional measure is suitable for scripts and
for troubleshooting docs.
