On 2025-02-15, Philip Webb wrote:

Recently, I bought 2 new Kingston Exodia 256 GB USB sticks
from Canada Computers, the store in Toronto I've used for 25 yr .
With many previous new USB sticks of sizes <= 128 GB
& which came with a VFat filesystem,
I simply repartitioned them using Fdisk, which created a Linux partition
& then used 'mke2fs' to format them with an Ext2 filesystem.
This time, something has gone wrong :

root:538 ~> mke2fs /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 60567296 4k blocks and 15147008 inodes
Filesystem UUID: 80c2f275-ed6b-4ef5-b785-b53bd225ca9e
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912,
819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000,
23887872
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information:
mke2fs: Input/output error while writing out and closing file system

I tried repartitioning the stick into 2 x 128 GB partitions,
in case it was the sheer size which was the problem, but got the same result. The error occured with both sticks, so it doesn't seem to be bad hardware.
It took 10 h 40 m to process the 256 GB part'n on my 2023 desktop machine,
so trying suggestions cb a rather long-drawn-out affair (smile).

Has anyone else encountered this ? Does anyone have suggestions ?

Are there kernel error or warning messages when this happens?

--
Nuno Silva

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday 15 February 2025 11:50:23 Greenwich Mean Time Nuno Silva wrote:

On 2025-02-15, Philip Webb wrote:

Recently, I bought 2 new Kingston Exodia 256 GB USB sticks
from Canada Computers, the store in Toronto I've used for 25 yr .
With many previous new USB sticks of sizes <= 128 GB
& which came with a VFat filesystem,
I simply repartitioned them using Fdisk, which created a Linux partition
& then used 'mke2fs' to format them with an Ext2 filesystem.

This time, something has gone wrong :
root:538 ~> mke2fs /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 60567296 4k blocks and 15147008 inodes
Filesystem UUID: 80c2f275-ed6b-4ef5-b785-b53bd225ca9e
Superblock backups stored on blocks: 32768, 98304, 163840, 229376,
294912,

819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424,
20480000, 23887872

Allocating group tables: done
Writing inode tables: done

Writing superblocks and filesystem accounting information:
mke2fs: Input/output error while writing out and closing file system

I tried repartitioning the stick into 2 x 128 GB partitions,
in case it was the sheer size which was the problem, but got the same result. The error occured with both sticks, so it doesn't seem to be bad hardware. It took 10 h 40 m to process the 256 GB part'n on my 2023 desktop machine, so trying suggestions cb a rather long-drawn-out affair (smile).

Has anyone else encountered this ? Does anyone have suggestions ?

Are there kernel error or warning messages when this happens?

An ext2fs with 4K block size has a maximum filesystem size limit of 16TiB.
Your 256GB drive will not experience a formatting problem because of its size.

Formatting a 256GB USB drive, especially if it is a USB 3.0 or later spec, should not take hours, but minutes if not seconds. Assuming there was no
power cut or interruption to the formatting operation the error has the smell of a hardware problem, hence dmesg should reveal if something went wrong with the device.

You can try reformatting the USB drive, while keeping an eye on the output of 'dmesg -W'.

If both of these sticks are behaving the same way, it could be the port on
your PC which has a problem. You can try using a different USB port to eliminate this causing the formatting failure.

Other than a hardware problem with the device itself, there is the chance of counterfeit USB drives, churned out at volume and having a smaller size and speed than advertised, or such poor quality flash chips they end up corrupting data. Usually they survive a reformat, at least with FAT, but can fail at any point thereafter.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmewlzwACgkQseqq9sKV ZxmiZRAArIPzLI3ud8KCKQNlt5X1gvY5dJ9tRpMm5vVNrWGw0iu2iLj5RmgFvVDO 68Hb5Ipxzx51d3ckSmZqd8fN9c2usnjZu/GtoMs1DnLufvdEh4Mykh6rxFw9N3P9 tsZ71iQmWNttf2TfpTXf+Pb2DeYZ4Q6F2X5SbHk7JldZrLZoxgG1QdXD39QZ+4Yl KxWRdJrGApWXqOlNFCyPWgn+2GQ79OsxysKgGKvBLRTn9IT6ViCVDTTpkXEJ17nt MrmakEHv+go0U89hgkPJ3KI4jRDMv6XWNx7cAHtCsbAXkihFOMCd+uybt4E5x0cm HsSGI2VPneqLreRmYaLF2QagO4/S2+idfottOtFrjwX7z+9Bkq9Wg1tN460q7uR2 cVYv1kb6HkQadalP0X8k1ZFhC72hEKWn44BBYekVIrj6p2x86x711xFhEMlIotZL 5kGL3bwRYOONXUIIuWSjoNgLpXLo6/jPm7JuGKV+Mw6W2eabxYYg55xR/Xqz0+sI A9GxGyz7Zn++WHx5AgiSY2yNG1pQ6GKJtcXdS0utuS31C/fNoyfgow9qKiVHotfG 4HvubHIxNM1kdJjip5DJc9ajCJ3C32KdvjM6sa228daz3MPuhpk9jLIzQnMzjnfI nBW13WKkexeGuHsebjmXG3FlBU4/MbzwrY3E6eyaaKnn1uwaJfY=
=Eyyv
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

250215 Michael wrote:

On Saturday 15 February 2025 11:50:23 Greenwich Mean Time Nuno Silva wrote:

On 2025-02-15, Philip Webb wrote:

Recently, I bought 2 new Kingston Exodia 256 GB USB sticks
from Canada Computers, the store in Toronto I've used for 25 yr .
With many previous new USB sticks of sizes <= 128 GB
& which came with a VFat filesystem,
I simply repartitioned them using Fdisk, which created a Linux partition & then used 'mke2fs' to format them with an Ext2 filesystem.

This time, something has gone wrong :
root:538 ~> mke2fs /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 60567296 4k blocks and 15147008 inodes
Filesystem UUID: 80c2f275-ed6b-4ef5-b785-b53bd225ca9e
Superblock backups stored on blocks: 32768, 98304, 163840, 229376,
294912,

819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424,
20480000, 23887872

Allocating group tables: done
Writing inode tables: done

Writing superblocks and filesystem accounting information:
mke2fs: Input/output error while writing out and closing file system

I tried repartitioning the stick into 2 x 128 GB partitions,
in case it was the sheer size which was the problem, but got the same result. The error occured with both sticks, so it doesn't seem to be bad hardware. It took 10 h 40 m to process the 256 GB part'n on my 2023 desktop machine, so trying suggestions cb a rather long-drawn-out affair (smile).

Has anyone else encountered this ? Does anyone have suggestions ?

Are there kernel error or warning messages when this happens?

An ext2fs with 4K block size has a maximum filesystem size limit of 16TiB. Your 256GB drive will not experience a formatting problem because of its size.

Formatting a 256GB USB drive, especially if it is a USB 3.0 or later spec, should not take hours, but minutes if not seconds.

See listing below. My notes tell me that in many previous cases,
it has taken these rates to format : 2 : 6 min/GB ; 3 : 1,8 min/GB ;
today, it took 2 h 51 m to format a 64 GB partition (mainly inodes).

Assuming there was no power cut or interruption to the formatting operation, the error has the smell of a hardware problem,
hence dmesg should reveal if something went wrong with the device.
You can try reformatting the USB drive,
while keeping an eye on the output of 'dmesg -W'.

Here's the output of the formatting + 'dmesg -W' ;
I used a different port, which is known to behave properly,
+ the other stick now re-partitioned to offer a 64 GB partition :

root:554 ~> t ; mke2fs /dev/sdb1 ; t
2025-02-15 Sat 17.57.46
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 16777216 4k blocks and 4194304 inodes
Filesystem UUID: 93b5ff29-fe5d-48e5-85b0-35b12bee226e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: mke2fs: Input/output error while writing out and closing file system
2025-02-15 Sat 20.48.04

dmesg 250215 21:12 : no messages while writing inode tables ;
different 3.0 port normally used without problem by scanner ;
'ls /dev' shows /dev/sdb sdb1 sdb2 sdb3 sdb4 still listed ;
stick is still in the port

root:635 ~> dmesg -W
[2023143.202399] usb 10-2: USB disconnect, device number 2
[2023143.210193] blk_print_req_error: 716 callbacks suppressed
[2023143.210196] device offline error, dev sdb, sector 95422464 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[2023143.210202] buffer_io_error: 1328 callbacks suppressed
[2023143.210203] Buffer I/O error on dev sdb1, logical block 11927552, lost async page write
[2023143.210218] device offline error, dev sdb, sector 95422472 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 2
[2023143.210221] Buffer I/O error on dev sdb1, logical block 11927553, lost async page write
[2023143.210259] device offline error, dev sdb, sector 95684608 op 0x1:(WRITE) flags 0x100000 phys_seg 2 prio class 2
[2023143.210264] Buffer I/O error on dev sdb1, logical block 11960320, lost async page write
[2023143.210269] Buffer I/O error on dev sdb1, logical block 11960321, lost async page write
[2023143.210277] device offline error, dev sdb, sector 95946752 op 0x1:(WRITE) flags 0x100000 phys_seg 2 prio class 2
[2023143.210280] Buffer I/O error on dev sdb1, logical block 11993088, lost async page write
[2023143.210283] Buffer I/O error on dev sdb1, logical block 11993089, lost async page write
[2023143.210302] device offline error, dev sdb, sector 96208896 op 0x1:(WRITE) flags 0x100000 phys_seg 2 prio class 2
[2023143.210305] Buffer I/O error on dev sdb1, logical block 12025856, lost async page write
[2023143.210308] Buffer I/O error on dev sdb1, logical block 12025857, lost async page write
[2023143.210312] device offline error, dev sdb, sector 96471040 op 0x1:(WRITE) flags 0x100000 phys_seg 2 prio class 2
[2023143.210315] Buffer I/O error on dev sdb1, logical block 12058624, lost async page write
[2023143.210342] Buffer I/O error on dev sdb1, logical block 12058625, lost async page write
[2023143.210351] device offline error, dev sdb, sector 96733184 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 2
[2023143.210373] device offline error, dev sdb, sector 96733192 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[2023143.210382] device offline error, dev sdb, sector 96995328 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 2
[2023143.210401] device offline error, dev sdb, sector 97257472 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 2
[2023143.926864] usb 10-2: new SuperSpeed USB device number 3 using xhci_hcd [2023143.946392] usb 10-2: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
[2023143.946397] usb 10-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2023143.946400] usb 10-2: Product: DataTraveler 3.0
[2023143.946402] usb 10-2: Manufacturer: Kingston
[2023143.946404] usb 10-2: SerialNumber: E0D55EA57410E8B189D80112 [2023143.946819] usb-storage 10-2:1.0: USB Mass Storage device detected [2023143.946993] scsi host12: usb-storage 10-2:1.0
[2023144.950983] scsi 12:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[2023144.951249] sd 12:0:0:0: Attached scsi generic sg1 type 0
[2023144.951349] sd 12:0:0:0: [sdb] 484540416 512-byte logical blocks: (248 GB/231 GiB)
[2023144.951913] sd 12:0:0:0: [sdb] Write Protect is off
[2023144.951917] sd 12:0:0:0: [sdb] Mode Sense: 45 00 00 00
[2023144.952478] sd 12:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[2023145.369087] sdb: sdb1 sdb2 sdb3 sdb4 < >
[2023145.369453] sd 12:0:0:0: [sdb] Attached SCSI removable disk

I can't make sense of the "USB disconnect" at the beginning
nor the "Attached SCSI removable disk" at the end :
I didn't touch anything during the whole process & have no removable disks.

If both of these sticks are behaving the same way,
it could be the port on your PC which has a problem.
You can try using a different USB port
to eliminate this causing the formatting failure.

I used the port normally used by my scanner with no problems.
The behaviour is the same.

Other than a hardware problem with the device itself,
there is the chance of counterfeit USB drives, churned out at volume
and having a smaller size and speed than advertised
or such poor quality flash chips they end up corrupting data.
Usually they survive a reformat, at least with FAT,
but can fail at any point thereafter.

That's very unlikely for sticks bought from a reputable store.
I've used Canada Computers since 2000 & had a problem only once,
a defective mobo for a new machine, which was replaced by another make.

Can anyone find anything of interest in the logs above ?

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatcadotinterdotnet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-02-16, Philip Webb wrote:

250215 Michael wrote:

On Saturday 15 February 2025 11:50:23 Greenwich Mean Time Nuno Silva wrote: >> > On 2025-02-15, Philip Webb wrote:

Recently, I bought 2 new Kingston Exodia 256 GB USB sticks
from Canada Computers, the store in Toronto I've used for 25 yr .
With many previous new USB sticks of sizes <= 128 GB
& which came with a VFat filesystem,
I simply repartitioned them using Fdisk, which created a Linux partition >> > > & then used 'mke2fs' to format them with an Ext2 filesystem.

This time, something has gone wrong :
root:538 ~> mke2fs /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)

[...]

Writing superblocks and filesystem accounting information:
mke2fs: Input/output error while writing out and closing file system [...]
Has anyone else encountered this ? Does anyone have suggestions ?

Are there kernel error or warning messages when this happens?

An ext2fs with 4K block size has a maximum filesystem size limit of 16TiB. >> Your 256GB drive will not experience a formatting problem because of its size.

Formatting a 256GB USB drive, especially if it is a USB 3.0 or later spec, >> should not take hours, but minutes if not seconds.

See listing below. My notes tell me that in many previous cases,
it has taken these rates to format : 2 : 6 min/GB ; 3 : 1,8 min/GB ; today, it took 2 h 51 m to format a 64 GB partition (mainly inodes).

Assuming there was no power cut or interruption to the formatting operation, >> the error has the smell of a hardware problem,
hence dmesg should reveal if something went wrong with the device.
You can try reformatting the USB drive,
while keeping an eye on the output of 'dmesg -W'.

Here's the output of the formatting + 'dmesg -W' ;
I used a different port, which is known to behave properly,
+ the other stick now re-partitioned to offer a 64 GB partition :

root:554 ~> t ; mke2fs /dev/sdb1 ; t
2025-02-15 Sat 17.57.46
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 16777216 4k blocks and 4194304 inodes
Filesystem UUID: 93b5ff29-fe5d-48e5-85b0-35b12bee226e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: mke2fs: Input/output error while writing out and closing file system
2025-02-15 Sat 20.48.04

dmesg 250215 21:12 : no messages while writing inode tables ;
different 3.0 port normally used without problem by scanner ;
'ls /dev' shows /dev/sdb sdb1 sdb2 sdb3 sdb4 still listed ;
stick is still in the port

root:635 ~> dmesg -W
[2023143.202399] usb 10-2: USB disconnect, device number 2
[2023143.210193] blk_print_req_error: 716 callbacks suppressed [2023143.210196] device offline error, dev sdb, sector 95422464 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[2023143.210202] buffer_io_error: 1328 callbacks suppressed
[2023143.210203] Buffer I/O error on dev sdb1, logical block 11927552, lost async page write
[2023143.210218] device offline error, dev sdb, sector 95422472 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 2

[...]

[2023143.210401] device offline error, dev sdb, sector 97257472 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 2
[2023143.926864] usb 10-2: new SuperSpeed USB device number 3 using xhci_hcd [2023143.946392] usb 10-2: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
[2023143.946397] usb 10-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2023143.946400] usb 10-2: Product: DataTraveler 3.0
[2023143.946402] usb 10-2: Manufacturer: Kingston
[2023143.946404] usb 10-2: SerialNumber: E0D55EA57410E8B189D80112 [2023143.946819] usb-storage 10-2:1.0: USB Mass Storage device detected [2023143.946993] scsi host12: usb-storage 10-2:1.0
[2023144.950983] scsi 12:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[2023144.951249] sd 12:0:0:0: Attached scsi generic sg1 type 0 [2023144.951349] sd 12:0:0:0: [sdb] 484540416 512-byte logical blocks: (248 GB/231 GiB)
[2023144.951913] sd 12:0:0:0: [sdb] Write Protect is off
[2023144.951917] sd 12:0:0:0: [sdb] Mode Sense: 45 00 00 00
[2023144.952478] sd 12:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[2023145.369087] sdb: sdb1 sdb2 sdb3 sdb4 < >
[2023145.369453] sd 12:0:0:0: [sdb] Attached SCSI removable disk

I can't make sense of the "USB disconnect" at the beginning
nor the "Attached SCSI removable disk" at the end :
I didn't touch anything during the whole process & have no removable
disks.

If both of these sticks are behaving the same way,
it could be the port on your PC which has a problem.
You can try using a different USB port
to eliminate this causing the formatting failure.

I used the port normally used by my scanner with no problems.
The behaviour is the same.

The device disconnected and then reconnected, this hopefully means there
is nothing wrong with the flash stick itself, that you just have to
figure out what is disconnecting it: lack of power, bad cable (if
applicable), usb power saving...

I've seen USB3 devices be very unstable when connected directly to some
USB ports. Adding a (USB extension, all of this with USB A) cable solved
the issue on the machine I saw that on. But that's probably not the
case, unless what you're seeing is mostly reproducible but random in how
long it takes to manifest (i.e. time between mkfs and the first
disconnect message in the kernel log).

--
Nuno Silva

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday 16 February 2025 09:08:10 Greenwich Mean Time Nuno Silva wrote:

On 2025-02-16, Philip Webb wrote:

250215 Michael wrote:

Formatting a 256GB USB drive, especially if it is a USB 3.0 or later
spec, should not take hours, but minutes if not seconds.

See listing below. My notes tell me that in many previous cases,
it has taken these rates to format : 2 : 6 min/GB ; 3 : 1,8 min/GB ; today, it took 2 h 51 m to format a 64 GB partition (mainly inodes).

I just formatted a USB 2.0 8GB stick with mke2fs as a test. It took 46 seconds. Extrapolating for your 64GB partition it should take ~ 6 minutes. A full 256GB drive would take 24.5 minutes. I expect a drive enjoying USB 3.0 transfer speeds to take way less than this.

root:635 ~> dmesg -W
[2023143.202399] usb 10-2: USB disconnect, device number 2
[2023143.210193] blk_print_req_error: 716 callbacks suppressed [2023143.210196] device offline error, dev sdb, sector 95422464 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2 [2023143.210202] buffer_io_error: 1328 callbacks suppressed
[2023143.210203] Buffer I/O error on dev sdb1, logical block 11927552,
lost async page write [2023143.210218] device offline error, dev sdb, sector 95422472 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 2

[...]

[2023143.210401] device offline error, dev sdb, sector 97257472 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 2 [2023143.926864] usb
10-2: new SuperSpeed USB device number 3 using xhci_hcd [2023143.946392] usb 10-2: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10 [2023143.946397] usb 10-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [2023143.946400] usb 10-2: Product: DataTraveler 3.0 [2023143.946402] usb 10-2: Manufacturer: Kingston
[2023143.946404] usb 10-2: SerialNumber: E0D55EA57410E8B189D80112 [2023143.946819] usb-storage 10-2:1.0: USB Mass Storage device detected [2023143.946993] scsi host12: usb-storage 10-2:1.0
[2023144.950983] scsi 12:0:0:0: Direct-Access Kingston DataTraveler
3.0 PMAP PQ: 0 ANSI: 6 [2023144.951249] sd 12:0:0:0: Attached scsi
generic sg1 type 0
[2023144.951349] sd 12:0:0:0: [sdb] 484540416 512-byte logical blocks:
(248 GB/231 GiB) [2023144.951913] sd 12:0:0:0: [sdb] Write Protect is off [2023144.951917] sd 12:0:0:0: [sdb] Mode Sense: 45 00 00 00 [2023144.952478] sd 12:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [2023145.369087] sdb: sdb1 sdb2 sdb3 sdb4 < >
[2023145.369453] sd 12:0:0:0: [sdb] Attached SCSI removable disk

I can't make sense of the "USB disconnect" at the beginning

This is the message you get when you physically unplug a USB drive.

nor the "Attached SCSI removable disk" at the end :

This is the message you get when the device is powered up, detected by the kernel and the filesystem is then being accessed. From this point on the device can be read from and written to.

I didn't touch anything during the whole process & have no removable
disks.

Needless to say, if you did not touch the USB stick when the disconnection message was recorded something disconnected (electrically) the device.

If both of these sticks are behaving the same way,
it could be the port on your PC which has a problem.
You can try using a different USB port
to eliminate this causing the formatting failure.

I used the port normally used by my scanner with no problems.
The behaviour is the same.

Hmm ... this points to the USB sticks, rather than the ports on your device.

The device disconnected and then reconnected, this hopefully means there
is nothing wrong with the flash stick itself, that you just have to
figure out what is disconnecting it: lack of power, bad cable (if applicable), usb power saving...

Wouldn't the same problem manifest with other USB sticks? That said, I have
an old USB stick which fails to connect properly if I push it in all the way
in a port. I have to push it in, then imperceptibly try to pull it out to
make good electrical contact with the port. I've blamed corrosion on the electrical strips inside the USB connector - it had been dropped in a mug of coffee at some point! Philip's USB sticks are brand new.

I've seen USB3 devices be very unstable when connected directly to some
USB ports. Adding a (USB extension, all of this with USB A) cable solved
the issue on the machine I saw that on. But that's probably not the
case, unless what you're seeing is mostly reproducible but random in how
long it takes to manifest (i.e. time between mkfs and the first
disconnect message in the kernel log).

I've had a similar problem with a new USB 3.0 stick. I can't recall the make/ model, but it was not some cheap knock-off. The speeds were glacial, rsync would fail sooner or later when copying data over, disconnections were shown
on dmesg and the stick would become really hot to touch. I tried reformatting it with FAT, ext2 and finally with F2FS, with improving performance each time due to the lighter load placed by the filesystem type on the device. However, the disconnections and failures continued until I returned it as a faulty product. Unlike the more expensive USB SSD drives, the onboard controller of the lower cost USB flash sticks tend to be cheap and unsophisticated, with a higher probability of early failure.

Other than a hardware problem with the device itself,
there is the chance of counterfeit USB drives, churned out at volume
and having a smaller size and speed than advertised
or such poor quality flash chips they end up corrupting data.
Usually they survive a reformat, at least with FAT,
but can fail at any point thereafter.

That's very unlikely for sticks bought from a reputable store.
I've used Canada Computers since 2000 & had a problem only once,
a defective mobo for a new machine, which was replaced by another make.

"Reputable store" these days implies they will not try to rob you, they have some rudimentary technical knowledge about their products and you can return faulty products for a replacement/refund. Other than that they are all box- shifters of products typically manufactured in the Far East at minimum cost
and invariably with very little quality control.

Regarding the USB stick marketed as Kingston Exodia 256 GB, the dmesg shown brand and model "idVendor=0951, idProduct=1666" helps identify it as being the same with the older Kingston DataTraveler 100 G3/G4/SE9 G2/50:

https://devicehunt.com/view/type/usb/vendor/0951/device/1666

If you intend to return it to the store, first reformat it with FAT and do not mention your ext2 experience, in case they try to blame that as the cause of your disconnections.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmex6vYACgkQseqq9sKV Zxm1/xAAjPRp93bNM72hmUZOSnC+LlLQnibx2Tpe5D/XSX6B9X6ce2CWHszCKJ4p TKNEQaQZSzPeP2WPVDQKllud4DwVk3Kpzqui1OeWGACbSZUtY0vC+JmQGbK5w/0T q7VGRVhkW063rgPmAOnYvOkXULwwFV8CDx5OoUsExRBUuQQkHYX5xUwvZaypDBFu jKZVlPp9V5hQ+ECaZa7Ax0n864upj1R5Af43/SQxX99G9yOYyzYIB53C6TDjTbuB Lz4KCLzdVBif7twkszSrHL+JPApglFZMppmg8B85NrCV5+yeVoXNfHo8bMc3OMtK 4V6+kOFfUqJHXsSqoUBsH741iwb0xHJgfToO6LmczrjD5cKCik96Oi3jSqmqVKR0 xoWFDBqOdwRhSY8d2pI6b8/Ey8FTBQlDXGNjPM+dhI1+63vyc5MRLKu/q5apEPA9 dqu4ozOCPSTrsIYNg08ZPwpXDAuEcy3JLucBAF23fopMsAumOiMJUyl7saRqnGga nEWLsZCBve26XWxBiGcJlfLCkL2nRahO3miFA5WpsH/rnBCdChIN8xyky/RWrCPy QE3MVemW4U0gzaUddWwHYeLGy4AXxfBcfFn0ajVj2HoEBVlI+tdsGH8DbQEFHjbR V8rd2HmfwapO8onQmZUHc7mYuQ6npuFjDpACpBiGYQdgPQtSI1o=
=Sq/B
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/02/2025 13:41, Michael wrote:

nor the "Attached SCSI removable disk" at the end :

This is the message you get when the device is powered up, detected by the kernel and the filesystem is then being accessed. From this point on the device can be read from and written to.

So (and this was my instant reaction on first reading the thread), is
that you might be getting messages that you should expect but naively
didn't.

You expect a message to say "detected USB drive". You expect a message
to say "accessing file system(s)".

Except you then ran fdisk and deleted the MBR/GPT! So you're going to
get a bunch of (possibly unexpected) messages about filesystems going
away and reappearing ...

I'm not sure what else is going to happen, but there might be more
"unexpected but obvious in hindsight" messages flying around.

The other thing. USB. Does all sorts of weird things. Just because your
USB stick is USB3 doesn't mean you're going to get USB3 performance from
it. Much as I don't like gaming mobos, you can reasonably assume
manufacturers aren't gaming the system here - there's too many
knowledgable people who will catch them out ...

But a possible scenario is the mobo has a single USB3 hub (probable, it
can handle 128 devices) wired into the mobo, with a USB2 hub wired into
the USB3 hub. I doubt it has a USB1 hub ... But some cheap USB hubs run
at the speed of the slowest device - if your scanner is plugged in,
live, and advertises itself as USB2, it could downgrade a cheap USB3 hub
to USB2! Ouch! Or if it's just plugged into a USB2 port and holding the
USB2 hub live!

Completely different, but I think I've just debugged a pain point at
home. I've got a telco-supplied mesh network, which is crap. So I run ethernet-over-power, which WAS crap. Dunno why. Buy a tp-link router,
configure it as an access point over CAT-5, plug the master
ethernet-over-power into the access point not the telco hub, and bingo, everything is working so much better! Your trouble with these sticks is probably the same, make a couple of changes that as far as you can see
should make no difference whatsoever, but they make a massive
improvement instead ...

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, Feb 16, 2025 at 01:41:10PM +0000 schrieb Michael:

On Sunday 16 February 2025 09:08:10 Greenwich Mean Time Nuno Silva wrote:

On 2025-02-16, Philip Webb wrote:

250215 Michael wrote:

Formatting a 256GB USB drive, especially if it is a USB 3.0 or later
spec, should not take hours, but minutes if not seconds.

See listing below. My notes tell me that in many previous cases,
it has taken these rates to format : 2 : 6 min/GB ; 3 : 1,8 min/GB ; today, it took 2 h 51 m to format a 64 GB partition (mainly inodes).

I just formatted a USB 2.0 8GB stick with mke2fs as a test. It took 46 seconds. Extrapolating for your 64GB partition it should take ~ 6 minutes. A
full 256GB drive would take 24.5 minutes. I expect a drive enjoying USB 3.0 transfer speeds to take way less than this.

Your expectations have some vague assumptions:
- the stick achieves full speed of its USB protocol
- it keeps that throughput over time
- the data written grows linearly with the FS size

USB sticks often have a bad thermal design and throttle down once they get hot. And hot they get, especially the high-speed ones.

If you are curious, use a program like dool or glances to observe the device’s actual write throughput during formatting. htop can show this, too, but you first need to add a display meter in its config.

--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

For Sale:
Parachute. Used once. Never opened. Slightly stained.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEVbE9o2D2lE5fhoVsizG+tUDUMMoFAmezwnsACgkQizG+tUDU MMpnjQ/+MEdDQtBnAYgcQkjixsFXeS9kQFxYMaUK/E8dMyv73wxjRgZxNpHEBKoh FxHtCa4oorhlqfwKuuqerxOT3Qq55qlEjotSKDb0eB0HFNYgEKN8Eq0RuShgP5zH aM6y1y7tsmcQvDzeWqKgSHfSyShnojQNJz9kcKNB8/+ybdr7M9bMib13IuWby+3x dVW4Y7svt9bg85DeLg+w/EeidbWRML+ctcbMXL5/BUbYPnJ0GMFEwN/DVIumNz4K zAl+x8SjnbxHxXHvgwEWHQ5loZDdTIt4qEPpjCJbhIy4s1LckPRy8HkZx7oiA3DV 9L1/rjgxyD89u5Uwh+6bY9fvfQgoccixsbmq6xqs6MeOjUZR/nuoHT2Tv8Fvv79s YBztFXymi8PITHMz5OIb6H+929To3rjFXlxhxNEoOOJmS/sYMMvLEm1XmMJOt8dO cdsMCLA6Fjeh2WxLf9ZRpsMGRPxCFZ2xAJGN88UU1WlHoyZ4YevmoMPLA5XNV+Oh 7Vik03SiUckTpYYMnUvYCpkvHGG4NoEzl0BODZFpx+tetj7IkYBRvj/rpwwgOMtI jXOvauxnVwTWIzvuy86r7MSY0jyJvsLiu19ToKbLcMMLKQdLAVtwx+FWQeJTtBc1 l1Lm8GBYsIwHvasszyR/UNpjkLy0PM40zuoESxdZNUWHLBxMdN4=
=q0xI
-----END

On Monday 17 February 2025 23:12:59 Greenwich Mean Time Frank Steinmetzger wrote:

Am Sun, Feb 16, 2025 at 01:41:10PM +0000 schrieb Michael:

I just formatted a USB 2.0 8GB stick with mke2fs as a test. It took 46 seconds. Extrapolating for your 64GB partition it should take ~ 6
minutes. A full 256GB drive would take 24.5 minutes. I expect a drive enjoying USB 3.0 transfer speeds to take way less than this.

Your expectations have some vague assumptions:

Yes, I was just trying to point loosely at the order of magnitude as an indication of something being faulty in the USB Philip was trying to format.

- the stick achieves full speed of its USB protocol

I haven't yet found a USB stick which reaches the maximum USB protocol speeds.
The old USB 2.0 stick I used will not go above 11-12MBps during large writes and around twice as fast on sustained reads, well below the advertised USB 2.0 speed of 60MBps.

- it keeps that throughput over time

Once buffers are saturated write operations will settle at what the device can achieve. I have observed writes slow down when the empty space left is getting low.

- the data written grows linearly with the FS size

Usually larger USB drives of the same brand/model tend to have slightly better speeds - at least this is what the data sheet for the USB drive Philip bought claims.

USB sticks often have a bad thermal design and throttle down once they get hot. And hot they get, especially the high-speed ones.

If you are curious, use a program like dool or glances to observe the device’s actual write throughput during formatting. htop can show this, too,
but you first need to add a display meter in its config.

I use gkrellms on GUI, and 'watch -d vmstat -d -S M' when on a console, but I've also used htop.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAme0dMwACgkQseqq9sKV ZxllCQ//fRJNkhat49uqQnM5pg9vR0OjgJJVbWAYTRg378iqsaHulUeQbdwEsfAL klGyM0djSdYddtY0GVPztyPTgqu3+1wTOfzuuE+PHupud56nx/VEjGN7o1E7lRtZ DbLhcaXFkHEPPyWvj8vuJzEqaYmwGD39Hvgq0DrWYJX0NJzxr5FQKShcaP4n76sP iUf8BxtIluZoj6mN/v530dGnFQfJyKKnKtc/TASSVXeaGRWLrbIhMRZEX/xiybKI cGUhpjMHRN2u12KwbSz0RUmeXqRDtDKWM5HJNXL23lq9RaMBH4Ay3/lrbBDxsosS 0s4m3bE0rVMjXyHOEspoWCW8j2oBE8u5tLFdb0yx067ItNC4xtClW4KNrOmGfNzT cHDrUT2k1YWLyBhzFKeFMUCVO5pJ6W+Q+h/WprbD1N1WDdt/do8hkZgZBc84Pwbr e40BDvoZRSeLlUBr+BSKETJjAfDgQraq+z5rZy+G5vOS9ci+mLfqtFzIXKTU+reM WDopC99u/vYkLghd2/qKXwIJ4/IKyGEjRxOXoOIWSB8x/rGBfXSybxiGv8LkKtvi 7FLMZd1Jr2qiwPcXFZCoDRFcYwa5Pc5PDl1cm8A+6QShr6se8B4FopdI62nNJpvZ ul+83Cv1jkVoixF0BF33T9cELrCDhWThCq6bf8UTvTJ9XHskxeE=
=aKN9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Tue, Feb 18, 2025 at 11:53:48AM +0000 schrieb Michael:

Your expectations have some vague assumptions:

Yes, I was just trying to point loosely at the order of magnitude as an indication of something being faulty in the USB Philip was trying to format.

- the stick achieves full speed of its USB protocol

I haven't yet found a USB stick which reaches the maximum USB protocol speeds.
The old USB 2.0 stick I used will not go above 11-12MBps during large writes and around twice as fast on sustained reads, well below the advertised USB 2.0
speed of 60MBps.

I’ve never seen more than 40 MB/s, also with USB 3.0 HDDs attached to a 2.0 port.

- it keeps that throughput over time

Once buffers are saturated write operations will settle at what the device can
achieve. I have observed writes slow down when the empty space left is getting low.

Which buffer? Sticks don’t generally have one, let a lone an equivalent to an SSD’s SLC cache. I guess you mean the host’s cache?

--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

For security reasons, all text in this mail is double-rot13 encrypted.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEVbE9o2D2lE5fhoVsizG+tUDUMMoFAme1ylMACgkQizG+tUDU MModtg/9HgxUmiqgEn1yvw9/xAgz6j7vajtcJrte4//kB3kkW2pYmvNdkWF3OV9R KHSzLnMWLgw/5Q2hj9J61Q1D7Cxd5J8C7h7XDJ9ffYWjgbrq5SWx3KXUXvBQ9qSX +EJuZOwvjF1RMqAUcoJwEo4qoaciy1EKeYj/+yrzc6QGX7wnz1pb8X2Y7jcTaJs7 FpPB9JWwDstEBlLb5jrMD4psw1sD9YHipL8lpslrbb6PYGV3hwjVqQRl0EVuIlC3 iCsiBzZE+7QeucmiPbcS9fek1cpskjucT9gcNg4DMKYx/qDazhBP7jYuo2TCJ8cE uWyVkWgUO9Y1iI9CGguozKaq+DCAsJrkn+wCat5KqD5yymBzkO2qVi6GVqN2ktDI Rn+cpte6523+/P+Zqcg7XheG1Qe1OIqgkHxqyzqtloZsEvLYokAvLuMk6KR/SoHf Vf5l3gKbH4VFAB6Bajqtf4PsHqMKDbf0i8MyDbiUnbOFj3+joB9ui/yr0wIsduNK XsZx9Yq+dY6v6kEfmXnwVWcdR6Th0Z+t9SuIv4RX/aze6yDl2g1EIObizZKzo7LN l/UmMtkw28QgUAZQvUHJWhPQW0b9QY2BV8ykDqidAIiTje6jqoI0e5feKYn4PbkU fS2KVCGzXtW0GTW8jilw6397QC5Pg/Rlk8864B+G+/tqeX2Xv5s=
=lpfN
-----EN

On Wednesday 19 February 2025 12:10:59 Greenwich Mean Time Frank Steinmetzger wrote:

Am Tue, Feb 18, 2025 at 11:53:48AM +0000 schrieb Michael:

Once buffers are saturated write operations will settle at what the device can achieve. I have observed writes slow down when the empty space left
is getting low.

Which buffer? Sticks don’t generally have one, let a lone an equivalent to an SSD’s SLC cache. I guess you mean the host’s cache?

Yes. I'm talking about dumb USB sticks with no onboard DRAM. You can see initially a small duration upsurge in speed, before the data transfer settles to steady state. After the command completes (cp , dd, etc.) and exits in the terminal, there is still data shown being transferred for some seconds until the buffer empties.

When carrying out successive tests you have to empty the buffers to obtain accurate results.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAme2/LYACgkQseqq9sKV ZxmUDw//WkPK5/s8L4ETOn4aY4lD8obH287lIusVBpJMaKCW+yRKhWNpTBLntGPc 0tHCOjQoJwj6vWd+pCQzy3ID6OV1W3mUe/ydOg+tTWwzT12aikdPZm3DutphevOc 0TGOVvHmDqw2TiGONxDEtRq+FWLV6LVUs/VCYJZEvpWUy+8YIWBuJ3OWvhoFoM1R Ytqfy4rLMEabBgRogqGivTUFSgHZ3Vkd9/OtsJ8Qkk7aagK//hKFoKBW6ZkLCiMw 8U2mwW0uPLsSXPfuGrPo9FqgITVU4TQaQkklTB5IELm8Gwwf6qChvQ9s7BhCxTwO fKcZrQaOvR0vx6f10kndZ6c29uzd0jzDGvFeB5I2yX3iPcSh/IbqFjyQ2p+Gw+pU SATS8Lu/Wi3FvWSNQV79aO8qvhqtu26ls+VjyxqhmBFoK1kQDiPaUnedl6Njmvsm 3QFggCCFb+/NyZ2L6gVvoWlthBqi6WH1Swn/0abp5yFaUWDhBrnmTPODt8Hn7f08 F2o2iewKB9GO3d6Q/aBO9cBWPkKJy1KnIN4kTq+HQoc0pq0t9tYa1lyQqUdoBOOu /E9wtqze51lD6xl1op/prugkhMXybG3wM1g6cVQqQxmD6wafUyNNlcF3FSMfvYKH szf3Ssz3ApP833gz4RFPmWxm508xgc2ICQhuTJySEko9ZPcPn3Q=
=bdKO
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)