On Mon, 11 Sep 2023 09:20:32 -0400, Carlos E. R. <robin_listas@es.invalid> wrote:

> On 2023-09-10 12:21, candycanearter07 wrote:
>> On 8/16/23 08:03, Marco Moock wrote:
>>> Am 16.08.2023 um 14:02:32 Uhr schrieb db:
>>>
>>>> How do I best (and fastest) format a USB stick with a format
>>>> that will allow copying files of any size onto it?
>>>> Preferably using a typed in command from the console.
>>>> I run Kubuntu 23.04.
>>>
>>> fsck.<filesystem> /dev/sdX
>>>
>>> Be aware that formatting doesn't delete all blocks on the device, some
>>> data will be recoverable.
>>>
>>
>> If you want to clear the hard drive, just do
>> sudo dd if=/dev/zero of=/dev/sdX status=progress
>>
>> BE VERY CAREFUL
>
> Do notice that an USB stick has limited write operations, so this does
> kill some life expectancy.
>
> And it is very slow.

If there is confidential info on the stick that you want to erase, then do
erase the whole thing.

If it's just to erase the partition table use
sudo dd if=/dev/zero of=/dev/sdX status=progress bs=1M count=1

Regards, Dave Hodgins

On 2023-09-11 10:45, The Natural Philosopher wrote:
> On 11/09/2023 14:36, Carlos E. R. wrote:
>> On 2023-09-11 04:45, The Natural Philosopher wrote:
>>> On 11/09/2023 07:57, Marco Moock wrote:
>>>> Am 11.09.2023 um 02:33:26 Uhr schrieb David W. Hodgins:
>>>>
>>>>> On Mon, 11 Sep 2023 02:15:37 -0400, Marco Moock
>>>>> <mm+usenet-es@dorfdsl.de> wrote:
>>>>>
>>>>>> Am 10.09.2023 um 18:41:30 Uhr schrieb David W. Hodgins:
>>>>>>> The 512 byte emulation was mostly used in the earliest 4k drives.
>>>>>>
>>>>>> Is seems to be still in use, even some modern SSDs have it.
>>>>>
>>>>> Most ssd drives do use 512 byte sectors, not emulated sectors.
>>>>
>>>> Is there a specific reason for that?
>>>>
>>> No., because it is simply not true
>>>
>>
>> Every SSD o nvme I have seen has 512 bytes sector sizes, both logical
>> and physical.
>>
>
> No, it has not. You have no way of knowing that.
>
> The physical read size is one bit, but the physical write size may be
> one bit or a whole erase block - at least 1MB.
>
> The manufactutrers do not normally tell you what that size is.

I did not say "erase block". I said "sector sizes". They are addressable
by LBA number, so their sizes are known with absolute accuracy.

--
Cheers,
Carlos E.R.

On 2023-09-11 11:43, The Natural Philosopher wrote:
> On 11/09/2023 15:43, candycanearter07 wrote:
>> On 9/11/23 09:37, Marco Moock wrote:
>>> Am 11.09.2023 um 09:31:57 Uhr schrieb candycanearter07:
>>>
>>>> So logical size is how much the chip writes and physical is the
>>>> actual block sizes?
>>>
>>> No, logical is what the chips tells the OS (512 was normal and some
>>> operating older systems had problems with 4096 or other values).
>>>
>>> Physical is the reals block size on the disk.
>>>
>>
>> Oh, so which one should you use?
>>
> Depends what you want to do.
> When erasing or block writing it is handy to know the size of the erase
> block, because your best chance of minimise writes to an SSD is to write
> blocks some multiple of that size.

Actually, it should not matter. The kernel should cache the writes and
delay the actual write operation till appropriate.

But testing shows that it matters.

And 'dd' is quite low level, anyway.

--
Cheers,
Carlos E.R.

On 12/09/2023 02:59, Carlos E. R. wrote:

>
> Actually, it should not matter. The kernel should cache the writes and
> delay the actual write operation till appropriate.
>

Not sure that dd doesn't bypass the cache and hit the drive hardware
directly.

> But testing shows that it matters.
>
> And 'dd' is quite low level, anyway.
>

--
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.

On 2023-09-12 02:33, The Natural Philosopher wrote:
> On 12/09/2023 02:59, Carlos E. R. wrote:
>
>
>>
>> Actually, it should not matter. The kernel should cache the writes and
>> delay the actual write operation till appropriate.
>>
>
> Not sure that dd doesn't bypass the cache and hit the drive hardware
> directly.

Not by default, you have to use "direct" flags, maybe others.

>
>> But testing shows that it matters.
>>
>> And 'dd' is quite low level, anyway.
>>
>

--
Cheers,
Carlos E.R.

On 2023-09-11, Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2023-09-10 12:21, candycanearter07 wrote:
>> On 8/16/23 08:03, Marco Moock wrote:
>>> Am 16.08.2023 um 14:02:32 Uhr schrieb db:
>>>
>>>> How do I best (and fastest) format a USB stick with a format
>>>> that will allow copying files of any size onto it?
>>>> Preferably using a typed in command from the console.
>>>> I run Kubuntu 23.04.
>>>
>>> fsck.<filesystem> /dev/sdX
>>>
>>> Be aware that formatting doesn't delete all blocks on the device, some
>>> data will be recoverable.
>>>
>>
>> If you want to clear the hard drive, just do
>> sudo dd if=/dev/zero of=/dev/sdX status=progress
>>
>> BE VERY CAREFUL
>
> Do notice that an USB stick has limited write operations, so this does
> kill some life expectancy.
>
> And it is very slow.
>

Does that apply to USB3 stick?

--
'Many have sought in vain to tell joyously of the Most Joyous. Now at last It declares
Itself to me, now in this misery.' - Holderlin
____
/. \
___________< |___________
\___________ ___________/
\___________ ___________/
\___________ ___________/
| |
^^^ ^^^
_________
| R W |
| (*) |
|____U____|

On 9/29/23 22:55, Rockinghorse Winner wrote:
> Does that apply to USB3 stick?
>
>

Why would it not? It's still mounted as a basic block device.
--
user <candycane> is generated from /dev/urandom

On 2023-09-30 05:55, Rockinghorse Winner wrote:
> On 2023-09-11, Carlos E. R. <robin_listas@es.invalid> wrote:
>> On 2023-09-10 12:21, candycanearter07 wrote:
>>> On 8/16/23 08:03, Marco Moock wrote:
>>>> Am 16.08.2023 um 14:02:32 Uhr schrieb db:
>>>>
>>>>> How do I best (and fastest) format a USB stick with a format
>>>>> that will allow copying files of any size onto it?
>>>>> Preferably using a typed in command from the console.
>>>>> I run Kubuntu 23.04.
>>>>
>>>> fsck.<filesystem> /dev/sdX
>>>>
>>>> Be aware that formatting doesn't delete all blocks on the device, some
>>>> data will be recoverable.
>>>>
>>>
>>> If you want to clear the hard drive, just do
>>> sudo dd if=/dev/zero of=/dev/sdX status=progress
>>>
>>> BE VERY CAREFUL
>>
>> Do notice that an USB stick has limited write operations, so this does
>> kill some life expectancy.
>>
>> And it is very slow.
>>
>
> Does that apply to USB3 stick?

Of course.

It may be a bit faster, though.

--
Cheers,
Carlos E.R.

On 30/09/2023 06:55, David W. Hodgins wrote:
> On Fri, 29 Sep 2023 23:55:37 -0400, Rockinghorse Winner
> <Rockinghorse@amgen.com> wrote:
>
>> On 2023-09-11, Carlos E. R. <robin_listas@es.invalid> wrote:
>>> On 2023-09-10 12:21, candycanearter07 wrote:
>>>> On 8/16/23 08:03, Marco Moock wrote:
>>>>> Am 16.08.2023 um 14:02:32 Uhr schrieb db:
>>>>>
>>>>>> How do I best (and fastest) format a USB stick with a format
>>>>>> that will allow copying files of any size onto it?
>>>>>> Preferably using a typed in command from the console.
>>>>>> I run Kubuntu 23.04.
>>>>>
>>>>> fsck.<filesystem> /dev/sdX
>>>>>
>>>>> Be aware that formatting doesn't delete all blocks on the device, some
>>>>> data will be recoverable.
>>>>>
>>>>
>>>> If you want to clear the hard drive, just do
>>>> sudo dd if=/dev/zero of=/dev/sdX status=progress
>>>>
>>>> BE VERY CAREFUL
>>>
>>> Do notice that an USB stick has limited write operations, so this does
>>> kill some life expectancy.
>>>
>>> And it is very slow.
>>>
>>
>> Does that apply to USB3 stick?
>
> A usb3 stick is faster than usb or usb2, but still slow compared to a
> spinning
> rust drive or an ssd.
>
> Regards, Dave Hodgins

A great deal of interesting stuff here

https://superuser.com/questions/253579/why-are-usb-flash-drives-so-much-slower-than-ssds

Probably best summarised as 'because largely they are cheap shit'

--
“The fundamental cause of the trouble in the modern world today is that
the stupid are cocksure while the intelligent are full of doubt."

- Bertrand Russell