Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 35 |
Nodes: | 6 (0 / 6) |
Uptime: | 30:52:07 |
Calls: | 322 |
Calls today: | 1 |
Files: | 959 |
Messages: | 81,855 |
Posted today: | 3 |
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 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.
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 asA USB drive which disconnects itself without interference by the user
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.
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'm currently testing a 2.0/1.1 port to write an Ext2 file system.
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' :[snip ...]
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)
wlp5s0: authenticate with 7a:ff:7b:47:c8:7f[snip ...]
[2132139.154945] wlp5s0: send auth to 7a:ff:7b:47:c8:7f (try 1/3)
[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).
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 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.