Other F2FS in FreeBSD

[YuryG]

Well,

I've put a bug report
PR 273201

it is marked “not a bug” like I was afraid it would be.

Although I could flawlessly use this pen-drive on Windows and copied the file from it to another flash stick. SHA512 summs are equal with the original file. (On this new flash drive it could be read fully on FreeBSD also, but it is an another drive, with a different capacity, a different virtual block size (don't know about a physical one) and even a different partitioning scheme — newer in GPR, problem flash stick is in MBR!)

Can't think what can I do to make such a bug reproducible.
I don't know if it was a “mitigated” somehow by Windows problem with a drive, or a rare bug in FreeBSD's exFAT implementation.
Again, I have fsck it in Windows with “scan for and attempt recovery of bad sectors” ON. Without an error.

For now I reformatted the “FreeBSD problem” flash drive in GPT scheme, recopied the file there, and awaiting bugs so far.

 

[YuryG]

exFat is meant to be fairly "optimized" for flash drives. Could this be an option?

The FUSE implementation is actually pretty good. Faster than NTFS.

By the way, is ntfs-3g really that slow??? I measured it on a USB3 stick and it's only 8.9Mibit/s on write. It's just awful! More than two hours(!) for 9GiB file to write? (At least it has 386Mibit/s for read…)

> time cp -v ./ToRome_w_Love_.mkv /mnt/yury/
./ToRome_w_Love_.mkv -> /mnt/yury/ToRome_w_Love_.mkv
0.016u 15.473s 2:15:06.41 0.1%    15+165k 72359+144243io 1pf+0w
> ls -l ./ToRome_w_Love_.mkv
-rw-r--r--  1 yury  wheel  9453049386 26 Oct  2018 ./ToRome_w_Love_.mkv

And on a slower Windows laptop with only a USB2 port the same stick gave me 42.4Mibit/s on write.

 

[YuryG]

Well,

it is marked “not a bug” like I was afraid it would be.

Although I could flawlessly use this pen-drive on Windows and copied the file from it to another flash stick. SHA512 summs are equal with the original file. (On this new flash drive it could be read fully on FreeBSD also, but it is an another drive, with a different capacity, a different virtual block size (don't know about a physical one) and even a different partitioning scheme — newer in GPR, problem flash stick is in MBR!)

Can't think what can I do to make such a bug reproducible.
I don't know if it was a “mitigated” somehow by Windows problem with a drive, or a rare bug in FreeBSD's exFAT implementation.
Again, I have fsck it in Windows with “scan for and attempt recovery of bad sectors” ON. Without an error.

For now I reformatted the “FreeBSD problem” flash drive in GPT scheme, recopied the file there, and awaiting bugs so far.

exFAT bugs are still there. Claimed to be

read[36818192286464] 65536 bytes from 1497104384 flags: 0x0
ERROR: failed to read cluster 0xe64f3.
   unique: 144, error: -5 (Input/output error), outsize: 16
unique: 145, opcode: READ (15), nodeid: 2, insize: 80, pid: 83779
read[36818192286464] 131072 bytes from 1497169920 flags: 0x0
ERROR: failed to read cluster 0xe64f6.

But again flawless in Windows, flawless in Linux. Just FreeBSD's exFAT implementation get this error ans developers answer "not a bug" for some reason.