Other USB fat32 flash drive is slow

G

gigilarosario

Hello,

I am running FreeBSD 14.2 with MATE since last month as my daily desktop - it is working amazingly well BUT I got this little problem - I have tried to copy files over my USB flash drive and it takes forever ! About 4MB/s ... I've tried from my user and root, it was a file from my ZFS fs to a FAT32 usb key. Do I need to add fuse support in the kernel or something like that - what's the trick ? I've tried with both USB2 / USB3 key and its slow.

Thank you very much !

Gigi
 
I've used mount_msdosfs and also Caja in MATE. Both gives me the same result. It's abnormally slow and hangs on large files...

rc.conf
Code: 
kld_list="amdgpu fusefs"
hostname="bsdtower"
ifconfig_em0="DHCP"
ifconfig_em0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
moused_nondefault_enable="NO"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
dbus_enable="YES"
slim_enable="YES"
webcamd_enable="YES"
vboxnet_enable="YES"
fusefs_enable="YES"

loader.conf
Code: 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
cryptodev_load="YES"
zfs_load="YES"
cuse_load="YES"
vboxdrv_load="YES"
fuse_load="YES"

$ pkg info | grep -i fuse
fusefs-exfat-1.4.0_1 Full-featured exFAT FS implementation as a FUSE module
fusefs-ext2-0.0.11_2 FUSE module to mount ext2, ext3 and ext4 with read write support
fusefs-libs-2.9.9_2 FUSE allows filesystem implementation in userspace
fusefs-ntfs-2022.10.3_1 Mount NTFS partitions (read/write) and disk images

Thanks!
 
You don't need FUSE for FAT filesystems. If there's one filesystem that is supported out of the box on almost every operating system out there, it's this one.
 
  • Like
Reactions: drr
bsduck said:
You don't need FUSE for FAT filesystems.
Click to expand...
Regardless the name FAT, exFAT requires FUSE, as it is quite different filesystem. FAT12 through FAT32 doesn't require FUSE, though.

And (not enough sure, though) FAT does not define all-over-the-world filename conversion (character encoding). For example, in Japan, both M$ and licensees (PC manufacturers) used ShiftJIS (CP932), but it is NOT used all over the world. And mis-matches in character encodings could confuse OS and apps without proper settings.

If this really matters, msdosfs_iconv_load="YES" in /boot/loader.conf and installing/configuring sysutils/kiconvtool could help. And descriptions about kiconvtool by Dmitry Marakasov would be helpful.

Just a FYI, I have
Code: 
kiconv_enable="YES"
kiconv_preload="YES"
kiconv_fstypes="msdosfs cd9660 udf"
kiconv_local_charsets="UTF-8"
kiconv_foreign_charsets="UTF-16LE UTF-16BE CP932 CP943 JP EUC-JP-MS ISO-2022-JP UTF-8"
in /etc/rc.conf for sysutils/kiconvtool.
 
Thank you. I'll try with better quality USB sticks and see if there is any difference. It's my only problem with FreeBSD :)

Everything is super quick, stable and reliable...Just that USB handling seems mysterious.
 
Some imitations would be far slower and much unreliable than genuine products by reliable manufacturers. From which merchants to buy would be quite important. And unfortunately, expensive does not mean it's genuine good product.

For short-term reliability, generating and comparing checksums (sha256, for example) before and after copy in both directions would help. And slowness could be acceptable in some use-cases of memsticks. Trade-offs.

More unfortunately, imitation sparkplugs could stop engines (mis-firing, broken noses, melted electrodes etc.), and worse, blow off the engine with detonations, severe knockings by unmatched heat ranges compared with genuine ones (typically, by NGK, Bosch or Denso and their OEMs). Slowness alone on memsticks are far more safer compared to it.
 
gigilarosario said:
Everything is super quick, stable and reliable...Just that USB handling seems mysterious.
Click to expand...
As others have pointed out already, the speeds that you are seeing are not unusual for common thumb drives.

Is your perception of slowness based on how files copy to this very same USB drive on another operating system? I have observed that in some other operating systems, the file manager shows a quick copy, but when I try to safely eject/remove the thumb drive, it takes some extra time to actually complete the data transfers and eject the drive. I think what happens there is the file manager assumes that the transfer is complete, when in reality it has only been written to a cache and the cached writes are synchronized to the drive only later on.
 
drr said:
I have observed that in some other operating systems, the file manager shows a quick copy, but when I try to safely eject/remove the thumb drive, it takes some extra time to actually complete the data transfers and eject the drive. I think what happens there is the file manager assumes that the transfer is complete, when in reality it has only been written to a cache and the cached writes are synchronized to the drive only later on.
Click to expand...
Exactly, I always notice this behaviour on Linux.
 
Just had my first kernel panic (it makes me sad), I have a core dump in /var/crash, is it easy to know where it crashed.. like getting some kind of stack trace? Thank you very much
 
You must log in or register to reply here.
Back
Top