/tech/ - Technology

PS: Flash drive is a brand new Intenso stick.

Did you partition the drive with fdisk or parted?
Does fdisk say anything about overlapping partition or wrong chs?
Does partx or partprobe load the table correctly?
Did you format with sdb1 unmounted?
Does sdb1 work as expected?

>>21164
>Did you partition the drive with fdisk or parted?
I used GParted first to shrink sdb1 and when file system creation failed, parted and mke2fs.

>Does fdisk say anything about overlapping partition or wrong chs?
The partitions don't overlap, there's even some empty sectors between them because 2048-sector-alignment was recommended by parted.

Current layout according to fdisk -l:

Disk /dev/sdb: 117.19 GiB, 125829120000 bytes, 245760000 sectors
Disk model: Alu Line        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe26d1a2d

Device     Boot    Start       End   Sectors   Size Id Type
/dev/sdb1           2048  12595200  12593153     6G  c W95 FAT32 (LBA)
/dev/sdb2       12597248 245759999 233162752 111.2G 83 Linux

>Does partx or partprobe load the table correctly?
Same result with partx, partprobe exits silently.

>Did you format with sdb1 unmounted?
I'm pretty sure sdb1 was unmounted in at least most of the test cases but I might try that later on. Shouldn't matter though.

>Does sdb1 work as expected?
I didn't try to ext4 format the first partition, might try that later.
Everything else works as expected, sdb1 is empty now (mkfs.vfat) but it behaved fine (booted antiX from sdb1, installed it to second machine, continued experimenting there).
Currently transferring 40GB of movies to sdb2 (btrfs)

>>21165
PS: I used e2fsck after formatting failed, it complained about a corrupted superblock and then went through every single inode because it "contains garbage data".
iirc I killed e2fsck before it finished its checks.
That was yesterday, maybe I'll repeat that on a tiny 10mb partition.

>>21164
>>21165
>Did you partition the drive with fdisk or parted?
Longer version:
sdb1 was created by a live usb creator on Windows because I did that at a friends place who wanted linux and it turned out they needed x86, which I didn't bring.
Then I GParted'd that partition at home, then I used mke2fs, then e2fsck, then everything, including dd to wipe the partition table.

OP here.

I ran

dmesg -l crit,err

as recommended here:
https://unix.stackexchange.com/questions/665332/mkfs-doesnt-work-hangs-on-creating-journal

And indeed it is full of errors:

[9524190.674912] blk_update_request: I/O error, dev sdb, sector 22706176 op 0x1:(WRITE) flags 0x100000 phys_seg 7 prio class 0
[9524190.674919] Buffer I/O error on dev sdb2, logical block 884736, lost async page write
[9524190.674926] Buffer I/O error on dev sdb2, logical block 884737, lost async page write
[9524190.674929] Buffer I/O error on dev sdb2, logical block 884738, lost async page write
[and plenty more]

I noticed that flash drives don't like it when there are lots of tiny write operations.
Bricked two sticks by installing linux directly instead of live booting but I never had trouble creating a fucking file system.

>>21168
>lost async page write
I would recommend mounting ext2 and other journal-less filesystem with the sync option.
>I noticed that flash drives don't like it when there are lots of tiny write operations.
You could test your theory by booting a bsd and dd-ing your filesystem of choice onto the raw disk (rsd1c) with a large block size. Linux only has buffered block devices. You might want to add conv=notrunc with a slow disk.

I'm starting to supect it's the flash drive or your usb hub is flaky.

>>21169
>I would recommend mounting ext2 and other journal-less filesystem with the sync option.
If this error message is from a journal-less filesystem then it must have come from btrfs, but thanks for the info.

>I'm starting to supect it's the flash drive or your usb hub is flaky.
It didn't work on two PCs with two OS's.
One is a 10 year old gaming rig, the other ancient prehistoric hardware someone gave away. Those should be different enough.

Lubuntu 5.x kernel, antiX 4.x kernel.

Could it be a bug in mkfs.ext4?
e2fsprogs: Lubuntu - 1.46.3, antiX - 1.46.2

Maybe its the flash drive, but why?
As I said above, even when I used cryptsetup and tried to format /dev/mapper/usb-encrypted I got the same result.

>>21170
PS: I'll test another flash drive later, gotta free it first.

>>21170
>Maybe its the flash drive, but why?
Io errors on block devices only happen with bad hardware, device drivers or partition tables, not because of partitioning tools.

Filesystems commonly have multiple superblocks for redundancy (they are at the sector numbers mkfs.ext2 prints during partitioning). Your fsck indicates all of them were garbage, so something must be very wrong.

Try this with e2fsck:

       -c     This  option  causes  e2fsck to use badblocks(8) program to do a
              read-only scan of the device in order to find  any  bad  blocks.
              If any bad blocks are found, they are added to the bad block in‐
              ode to prevent them from being allocated to a file or directory.
              If  this option is specified twice, then the bad block scan will
              be done using a non-destructive read-write test.

>>21173
>Try this with e2fsck -c -c
mkfs.ext4 -c -c tests for bad blocks before writing.
I downsized the btrfs sdb2 and created sdb3 for testing,
(0/0/0) errors and it still doesn't work.

Furthermore, searching for bad blocks on a usb stick is pointless afaik because those drives constantly check for bad blocks themselves, due to flash storage wearing out more easily than others.
Flash drives have an abundance of "secret" storage space that is activated whenever part of their memory breaks down.
This is the reason why data eraser tools can not reliably be used on flash drives
Afaik there's also custom driver software that you can put on USB keys to make that backup space accessible, thus increasing available storage space.

Back to me:
If on 128GB of storage even a small 1GB partition can not be ext2/ext4 formatted, that's impossible when 45 GB video data on 120GB btrfs partition can be written (and read again) flawlessly.

Btw here someone says it doesn't make sense at all to check for bad blocks on newer drives of any kind:
https://superuser.com/questions/1370054/checking-a-new-disk-for-bad-blocks-on-linux-does-read-only-make-sense