• [gentoo-user] problem formatting new 256 GB USB stick : more info

    From Philip Webb@21:1/5 to All on Mon Feb 17 00:00:02 2025
    I successfully formatted one of the partitions which failed with Ext2 as Vfat. I was able to mount it, create a file with words in it,
    save it, list it via 'ls', browse it & then delete it, all using Gentoo.
    This suggests that the problem isn't due to defective hardware,
    but is somewhere in 'mke2fs' or related material.

    Any observations are very welcome.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nuno Silva@21:1/5 to Philip Webb on Mon Feb 17 01:20:01 2025
    On 2025-02-16, Philip Webb wrote:

    I successfully formatted one of the partitions which failed with Ext2 as Vfat.
    I was able to mount it, create a file with words in it,
    save it, list it via 'ls', browse it & then delete it, all using Gentoo.
    This suggests that the problem isn't due to defective hardware,
    but is somewhere in 'mke2fs' or related material.

    Any observations are very welcome.

    I'd say this is very unlikely, and that you should test and investigate
    more, lest it have some issue that could lead to data loss later.

    --
    Nuno Silva

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Mon Feb 17 00:39:15 2025
    On Sunday 16 February 2025 22:57:29 Greenwich Mean Time Philip Webb wrote:
    I successfully formatted one of the partitions which failed with Ext2 as Vfat. I was able to mount it, create a file with words in it,
    save it, list it via 'ls', browse it & then delete it, all using Gentoo.
    This suggests that the problem isn't due to defective hardware,
    but is somewhere in 'mke2fs' or related material.

    Any observations are very welcome.

    A USB drive which disconnects itself without interference by the user does not indicate a problem caused by any filesystem in and of itself.

    However, a poor quality or buggy USB flash controller which drops the connection because it is overloaded by data, could produce all sort of random failures.

    I am no filesystem expert, but my thinking is an ext2 filesystem will try to commit more data to a block device than FAT does while formatted. Ext2 will write in many different blocks across the partition by creating backups of its superblock, inode bitmaps, inode tables, etc. If a USB drive cannot cope with this relatively simple transaction of committing to flash cells the structure of a filesystem, then it must have bigger problems.

    Instead of writing and deleting a simple text file, I would try to stress test the drive by copying over a more demanding workload in order to see if this succeeds without dmesg coming up with any more errors.

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

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmeyhTMACgkQseqq9sKV ZxnxBQ/9EomQbnnsUM8uaffPwo4gVv6JOzEsvgy3W+KUKgSHuuoOQweHdHTxiznd D/sSVT1pljZPM/Zv2Eh8/klelCfdTW/M2bwxKxluM6XC/5nFFkG0V5qPNDAKs3G/ lldy7gwUFxCObceQ9b4dK1OLQwIBScL9+wJT7N75PeBURDtDK9Xo2cTYALntwt6d 9xNHMFe8Cypr5cvMMuCUAaV6siIXpH+5QQFmmvGc7ikwYorbGvw3yEDm5oEBt0+E tOgA2VB3sWz5OpiPgO98SmXomFaCbMm3iSdqG7Pimq4gQ2jQBf9ZoHSjcOyX5CCC pmX3W7FI5Zcs2eQsoATZVNoF7INqbip8AXFz1X/Bjv2yYUgoNhbMdcki8m4Cv/s1 akYaz690Lra7iDP80krMBDZY7Q3nBA9dBMeS2NgG3vvEWjqKeYOgZCRDLmWhK1zL llAUK0YWV8ZOD9+H+gbMlFTugNZ7qtTErIPde/5xlISmvOgYmiYEBCTUUcT2Ca7B aVAy8rVJq/5kWrODIBIESGsGRF7uPIY/G54WFiOPG2uenJHRwYjjXMz576vo/Oyd 4ZKHN5H+0pH/SBHZskbpLS5hba6vrx+8rOkU4WcoHMtn4Yi4SiDQ3QTM5n5SrMbh rN/sjcJ0rDj4IApzMID25j2icBdJynpLxOvo8yUD8wnzfEoLyZU=
    =Xk6x
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philip Webb@21:1/5 to All on Mon Feb 17 04:50:01 2025
    250217 Michael wrote:
    On Sunday 16 February 2025 22:57:29 Greenwich Mean Time Philip Webb wrote:
    I successfully formatted one of the partitions which failed with Ext2 as
    Vfat. I was able to mount it, create a file with words in it,
    save it, list it via 'ls', browse it & then delete it, all using Gentoo.
    This suggests that the problem isn't due to defective hardware,
    but is somewhere in 'mke2fs' or related material.
    Any observations are very welcome.
    A USB drive which disconnects itself without interference by the user
    does not indicate a problem caused by any filesystem in and of itself. However, a poor quality or buggy USB flash controller
    which drops the connection because it is overloaded by data
    could produce all sort of random failures. I am no filesystem expert,
    but my thinking is an ext2 filesystem will try to commit more data
    to a block device than FAT does while formatted.
    Ext2 will write in many different blocks across the partition
    by creating backups of its superblock, inode bitmaps, inode tables, etc.
    If a USB drive cannot cope with this relatively simple transaction
    of committing to flash cells the structure of a filesystem,
    then it must have bigger problems. Instead of writing and deleting
    a simple text file, I would try to stress test the drive
    by copying over a more demanding workload
    to see if this succeeds without dmesg coming up with any more errors.

    I do hear you + Nuno clearly, but my own experience is
    that repeatable errors are the result of software problems
    -- incl eg omitted flags or inadequate config files --
    & random errors are caused by faulty hardware.
    This problem is repeatable with 'mke2fs' : do I need a flag or config ?
    -- that cb something which has changed with the latest 256 GB sticks.

    I'm currently testing a 2.0/1.1 port to write an Ext2 file system.
    If that makes no difference, I'll see if I can do your stress test above
    after recreating a FAT file system on one of the partitions.
    Another test mb to create a very small partition -- eg 5 GB --
    & see if 'mke2fs' wb able to format that without disconnecting.
    I'll report results when I have them (smile).

    The sticks were delivered, so I can't easily return them,
    & in any case we've had 50 cm snow dumped on us in the last few days.
    If a Linux file system really is unachievable,
    I can format the sticks as FAT, which sb adequate for simple archiving.

    Thanks to both of you for your advice so far.
    Comments from others are welcome too.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philip Webb@21:1/5 to All on Mon Feb 17 10:20:02 2025
    250216 Philip Webb wrote:
    I'm currently testing a 2.0/1.1 port to write an Ext2 file system.

    it succeeded ! -- results below :

    root:668 ~> t ; mke2fs /dev/sdb1 ; t
    2025-02-16 Sun 22.21.11
    mke2fs 1.47.0 (5-Feb-2023)
    Creating filesystem with 16777216 4k blocks and 4194304 inodes
    Filesystem UUID: c5de9632-b97e-4b9c-bfd5-d5c5af785d48
    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: done
    2025-02-17 Mon 02.36.25

    as cb seen, it took 4 h 15 m .
    there are differences in output from 'dmesg -W' :

    root:502 ~> dmesg -W
    [2125533.280237] usb 5-6.2: reset high-speed USB device number 6 using xhci_hcd
    [2126092.734294] wlp5s0: disconnect from AP 7a:ff:7b:47:c8:7f for new auth to 68:ff:7b:47:c9:13
    [2126092.829576] wlp5s0: authenticate with 68:ff:7b:47:c9:13
    [2126092.859893] wlp5s0: send auth to 68:ff:7b:47:c9:13 (try 1/3)
    [2126092.888971] wlp5s0: authenticated
    [2126092.889223] wlp5s0: associate with 68:ff:7b:47:c9:13 (try 1/3)
    [2126092.901777] wlp5s0: RX ReassocResp from 68:ff:7b:47:c9:13 (capab=0x1511 status=0 aid=1)
    [2126092.926490] wlp5s0: associated
    [2126092.926513] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 68:ff:7b:47:c9:13
    [2126171.655896] wlp5s0: disconnect from AP 68:ff:7b:47:c9:13 for new auth to 7a:ff:7b:47:c8:7f
    [2126171.735470] wlp5s0: authenticate with 7a:ff:7b:47:c8:7f
    [2126171.765556] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
    [2126171.871847] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 2/3)
    [2126171.875511] wlp5s0: authenticated
    [2126171.876841] wlp5s0: associate with 7a:ff:7b:47:c8:7f (try 1/3)
    [2126171.889248] wlp5s0: RX ReassocResp from 7a:ff:7b:47:c8:7f (capab=0x1511 status=0 aid=1)
    [2126171.914432] wlp5s0: associated
    [2126171.914464] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 7a:ff:7b:47:c8:7f
    [2128215.129375] wlp5s0: disconnect from AP 7a:ff:7b:47:c8:7f for new auth to 68:ff:7b:47:c9:13
    [2128215.229697] wlp5s0: authenticate with 68:ff:7b:47:c9:13
    [2128215.259597] wlp5s0: send auth to 68:ff:7b:47:c9:13 (try 1/3)
    [2128215.288570] wlp5s0: authenticated
    [2128215.289300] wlp5s0: associate with 68:ff:7b:47:c9:13 (try 1/3)
    [2128215.301360] wlp5s0: RX ReassocResp from 68:ff:7b:47:c9:13 (capab=0x1511 status=0 aid=1)
    [2128215.326165] wlp5s0: associated
    [2128215.334629] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 68:ff:7b:47:c9:13
    [2128230.472949] wlp5s0: disconnect from AP 68:ff:7b:47:c9:13 for new auth to 7a:ff:7b:47:c8:7f
    [2128230.548458] wlp5s0: authenticate with 7a:ff:7b:47:c8:7f
    [2128230.577576] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
    [2128230.681826] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 2/3)
    [2128230.684849] wlp5s0: authenticated
    [2128230.685838] wlp5s0: associate with 7a:ff:7b:47:c8:7f (try 1/3)
    [2128230.697992] wlp5s0: RX ReassocResp from 7a:ff:7b:47:c8:7f (capab=0x1511 status=0 aid=1)
    [2128230.723132] wlp5s0: associated
    [2128230.723154] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 7a:ff:7b:47:c8:7f
    [2129066.061800] wlp5s0: disconnect from AP 7a:ff:7b:47:c8:7f for new auth to 68:ff:7b:47:c9:13
    [2129066.140447] wlp5s0: authenticate with 68:ff:7b:47:c9:13
    [2129066.169621] wlp5s0: send auth to 68:ff:7b:47:c9:13 (try 1/3)
    [2129066.198602] wlp5s0: authenticated
    [2129066.199727] wlp5s0: associate with 68:ff:7b:47:c9:13 (try 1/3)
    [2129066.211388] wlp5s0: RX ReassocResp from 68:ff:7b:47:c9:13 (capab=0x1511 status=0 aid=1)
    [2129066.237270] wlp5s0: associated
    [2129066.265480] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 68:ff:7b:47:c9:13
    [2129068.686728] wlp5s0: disconnect from AP 68:ff:7b:47:c9:13 for new auth to 7a:ff:7b:47:c8:7f
    [2129068.768225] wlp5s0: authenticate with 7a:ff:7b:47:c8:7f
    [2129068.798339] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
    [2129068.904663] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 2/3)
    [2129068.907726] wlp5s0: authenticated
    [2129068.908705] wlp5s0: associate with 7a:ff:7b:47:c8:7f (try 1/3)
    [2129068.920407] wlp5s0: RX ReassocResp from 7a:ff:7b:47:c8:7f (capab=0x1511 status=0 aid=1)
    [2129068.945293] wlp5s0: associated
    [2129068.945703] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 7a:ff:7b:47:c8:7f
    [2130027.166965] wlp5s0: disconnect from AP 7a:ff:7b:47:c8:7f for new auth to 68:ff:7b:47:c9:13
    [2130027.265257] wlp5s0: authenticate with 68:ff:7b:47:c9:13
    [2130027.295129] wlp5s0: send auth to 68:ff:7b:47:c9:13 (try 1/3)
    [2130027.324148] wlp5s0: authenticated
    [2130027.324894] wlp5s0: associate with 68:ff:7b:47:c9:13 (try 1/3)
    [2130027.337042] wlp5s0: RX ReassocResp from 68:ff:7b:47:c9:13 (capab=0x1511 status=0 aid=1)
    [2130027.361233] wlp5s0: associated
    [2130027.369658] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 68:ff:7b:47:c9:13
    [2130029.835939] wlp5s0: disconnect from AP 68:ff:7b:47:c9:13 for new auth to 7a:ff:7b:47:c8:7f
    [2130029.930077] wlp5s0: authenticate with 7a:ff:7b:47:c8:7f
    [2130029.960635] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
    [2130030.067841] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 2/3)
    [2130030.070895] wlp5s0: authenticated
    [2130030.071832] wlp5s0: associate with 7a:ff:7b:47:c8:7f (try 1/3)
    [2130030.084165] wlp5s0: RX ReassocResp from 7a:ff:7b:47:c8:7f (capab=0x1511 status=0 aid=1)
    [2130030.108940] wlp5s0: associated
    [2130030.148960] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 7a:ff:7b:47:c8:7f
    [2132136.363825] wlp5s0: disconnect from AP 7a:ff:7b:47:c8:7f for new auth to 68:ff:7b:47:c9:13
    [2132136.456967] wlp5s0: authenticate with 68:ff:7b:47:c9:13
    [2132136.486972] wlp5s0: send auth to 68:ff:7b:47:c9:13 (try 1/3)
    [2132136.516000] wlp5s0: authenticated
    [2132136.516728] wlp5s0: associate with 68:ff:7b:47:c9:13 (try 1/3)
    [2132136.529204] wlp5s0: RX ReassocResp from 68:ff:7b:47:c9:13 (capab=0x1511 status=0 aid=1)
    [2132136.554633] wlp5s0: associated
    [2132136.663025] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 68:ff:7b:47:c9:13
    [2132139.033739] wlp5s0: disconnect from AP 68:ff:7b:47:c9:13 for new auth to 7a:ff:7b:47:c8:7f
    [2132139.124569] wlp5s0: authenticate with 7a:ff:7b:47:c8:7f
    [2132139.154945] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
    [2132139.260645] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 2/3)
    [2132139.263840] wlp5s0: authenticated
    [2132139.264645] wlp5s0: associate with 7a:ff:7b:47:c8:7f (try 1/3)
    [2132139.277129] wlp5s0: RX ReassocResp from 7a:ff:7b:47:c8:7f (capab=0x1511 status=0 aid=1)
    [2132139.302159] wlp5s0: associated
    [2132139.331597] wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 7a:ff:7b:47:c8:7f
    [2135034.469269] EXT4-fs (sdb1): mounting ext2 file system using the ext4 subsystem
    [2135043.577142] EXT4-fs (sdb1): mounted filesystem c5de9632-b97e-4b9c-bfd5-d5c5af785d48 r/w without journal. Quota mode: none.
    [2135217.544967] EXT4-fs (sdb1): unmounting filesystem c5de9632-b97e-4b9c-bfd5-d5c5af785d48.

    This seems to narrow the problem down to the USB 3.2 performance,
    which well mb affected by inferior devices on the stick.
    I was able to mount the partition, edit a file & browse it,
    but re-actions to commands are very slow.
    I'll try to format the other partitions on both sticks,
    tho' a final verdict will take some time (wry grin).

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Mon Feb 17 12:02:36 2025
    On Monday 17 February 2025 09:18:45 Greenwich Mean Time Philip Webb wrote:
    250216 Philip Webb wrote:
    I'm currently testing a 2.0/1.1 port to write an Ext2 file system.

    it succeeded ! -- results below :

    root:668 ~> t ; mke2fs /dev/sdb1 ; t
    2025-02-16 Sun 22.21.11
    mke2fs 1.47.0 (5-Feb-2023)
    Creating filesystem with 16777216 4k blocks and 4194304 inodes
    Filesystem UUID: c5de9632-b97e-4b9c-bfd5-d5c5af785d48
    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: done
    2025-02-17 Mon 02.36.25

    as cb seen, it took 4 h 15 m .

    This is an excessively long time for a USB 2.0 port, but thankfully the dmesg output no longer showed any disconnections.


    there are differences in output from 'dmesg -W' :

    root:502 ~> dmesg -W
    [2125533.280237] usb 5-6.2: reset high-speed USB device number 6 using xhci_hcd [2126092.734294] wlp5s0: disconnect from AP 7a:ff:7b:47:c8:7f for new auth to 68:ff:7b:47:c9:13 [2126092.829576] wlp5s0: authenticate with 68:ff:7b:47:c9:13
    [2126092.859893] wlp5s0: send auth to 68:ff:7b:47:c9:13 (try 1/3)
    [snip ...]

    wlp5s0: authenticate with 7a:ff:7b:47:c8:7f
    [2132139.154945] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
    [snip ...]

    [NOTE: Your wireless appears to be hunting for different AP BSSIDs to connect to. You could stop it doing this and interrupting your internet connection,
    by selecting the AP BSSID with the stronger signal (larger SNR). Set this in your wpa_supplicant.conf to stop it roaming.]


    [2135034.469269] EXT4-fs (sdb1): mounting
    ext2 file system using the ext4 subsystem [2135043.577142] EXT4-fs (sdb1): mounted filesystem c5de9632-b97e-4b9c-bfd5-d5c5af785d48 r/w without
    journal. Quota mode: none.
    [2135217.544967] EXT4-fs (sdb1): unmounting
    filesystem c5de9632-b97e-4b9c-bfd5-d5c5af785d48.

    This seems to narrow the problem down to the USB 3.2 performance,
    which well mb affected by inferior devices on the stick.

    Barring some temporary dust/debris in the USB port or USB stick's electrical contacts, in my mind the flash controller on these sticks seems highly
    suspect. I would not trust them with my data, unless I was transferring files from one device to another and data loss was not an issue.

    USB sticks are manufactured rather cheaply today and sadly their reliability leaves much to be desired. I recall reading somewhere, the flash controller
    on many USB sticks performs no (meaningful) wear levelling at all.


    I was able to mount the partition, edit a file & browse it,
    but re-actions to commands are very slow.
    I'll try to format the other partitions on both sticks,
    tho' a final verdict will take some time (wry grin).

    Instead of FAT or ext2 you may want you try formatting with f2fs, which was specifically designed for NAND flash devices, or if you want to have compatibility with MSWindows OS you can use exfat. Both are superior to FAT and F2FS in particular was designed for NAND flash storage. I have found F2FS to be faster and more reliable than alternatives on USB sticks. The only caution I have taken is to always access it with the same or more recent kernels compared to the one I formatted with.

    For exfat you'll need to set in your kernel:

    ~ $ grep EXFAT /usr/src/linux/.config
    # DOS/FAT/EXFAT/NT Filesystems
    CONFIG_EXFAT_FS=m
    CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
    # end of DOS/FAT/EXFAT/NT Filesystems

    For F2FS:

    ~ $ grep F2FS /usr/src/linux/.config
    CONFIG_F2FS_FS=y
    CONFIG_F2FS_STAT_FS=y
    CONFIG_F2FS_FS_XATTR=y
    CONFIG_F2FS_FS_POSIX_ACL=y
    CONFIG_F2FS_FS_SECURITY=y
    # CONFIG_F2FS_CHECK_FS is not set
    # CONFIG_F2FS_FAULT_INJECTION is not set
    CONFIG_F2FS_FS_COMPRESSION=y
    CONFIG_F2FS_FS_LZO=y
    CONFIG_F2FS_FS_LZORLE=y
    CONFIG_F2FS_FS_LZ4=y
    CONFIG_F2FS_FS_LZ4HC=y
    CONFIG_F2FS_FS_ZSTD=y
    CONFIG_F2FS_IOSTAT=y
    # CONFIG_F2FS_UNFAIR_RWSEM is not set

    For storage of (many) text and other compressible files you'd probably want to give some forethought to deploying compression, which will further reduce the load on the stick.

    NOTE: Read up on F2FS and exFAT before you used in production them as there
    are some warnings/considerations specific to them, which may make them unsuitable for your use cases.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmezJVwACgkQseqq9sKV ZxnaIw/8Dfv8R1lp0JMm2P4oPyn1x8fXrqHiJ/JpRMMzw4FkR0d6q/uEXt15NT2M FNyuKbIBTYTWlr44IPGlII2wPl8rMOqI7Er5nYnCdk8Ru5Q5EC5OjEo09YisDPqK 0RRFMdw4hFJU5tbGJeKETzBDOb7CvblbT9zXTCZIeNvzdCWiHbHVYmknWtcbGpVt loGXCX/7iBYWcj6gC62xXYrZsnGzakceAgEptplXVz4cmhynJCqrbI11DaiOY9nl re6mcbNTh71GX9HqjQq7QAwOHTLrrpuEKS75I7BLjCVO5xqyogK57l6dacGJDa0n 0lEH4x0xvFYNt4XS73Y4h85pRHsKFV/lmjWYcCxAo/YI91pYZpSsxREFJ5JIdN+6 xFlILP/83udgiAQktMAYy/5ynfB+33iQEPbf4VCuGpMNuUuupbahS9+SCHwcbZ7z vArnKzUAx6it0eL8sUacDIu0ODFBlw0fkF+SPB1CDrfgMFKaL8/mMSvzwituhb/h hBqj9qzpT0jG/j8jZATXyLewKVwXSesU3xXQsmnNDfvuPgLtjh9ubUcPBx27lR8P mF1lOR60XMHM0tMZaGYeONoCXgHOyl/JpffrhBOKZj1JC+R8Z0Odfg2Hz4va8VXC TVgOW5ucN64d78tpdSNgRq0NlZ//gFt3umh10V3pwmkPQj1SJ5M=
    =GJMC
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stroller@21:1/5 to All on Mon Feb 17 17:40:01 2025
    On 17 Feb 2025, at 12:02, Michael <confabulate@kintzios.com> wrote:

    as cb seen, it took 4 h 15 m .

    This is an excessively long time for a USB 2.0 port, but thankfully the dmesg
    output no longer showed any disconnections.

    The poor wee flash controller had to keep erasing the drive's 16MB of flash so many times so it could continue writing the file.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wols Lists@21:1/5 to Philip Webb on Mon Feb 17 17:30:01 2025
    On 17/02/2025 03:43, Philip Webb wrote:
    The sticks were delivered, so I can't easily return them,
    & in any case we've had 50 cm snow dumped on us in the last few days.
    If a Linux file system really is unachievable,
    I can format the sticks as FAT, which sb adequate for simple archiving.

    Don't you have "fit for purpose"? In the UK if the sticks won't reformat
    to ext2 or whatever you want them for, you'd just return them as not fit
    / faulty, and consumer protection law kicks in to say you're due a full
    refund.

    And if they say "it was provided as FAT, you shouldn't have reformatted
    it", well where did they say that when you bought it, and lots of uses
    (TVs etc) do advise you to reformat sticks.

    Plus of course, as was mentioned elsewhere, if it can't cope with a data
    load of reformatting, how do you know it's going to cope with other,
    different data loads?

    Cheers,
    Wol

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