Solved USB 3.0 [UFS] - Incredibly slow speed

ayleid96

ayleid96

Greetings,

I have two USB 3.0 Kingston flash drives and i always leave formatting options by default(block size 4096 bytes etc..) i only add label. usbconfig:

Code: 
ugen0.3: <Kingston DataTraveler 3.0> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (74mA)

When i format drives with MBR/FAT performance is good enough for home use. But when i format them with BSD/UFS that's when things go downhill(without journaling and soft-updates), am i making an error for formatting drives with UFS? I don't think that BSD partitioning scheme has to do anything with this. I also noticed that formatting takes little more than a minute.

UFS1/2 - 4 Megabytes per second - write
FAT - 24 Megabytes per second - write

Other useful info maybe:
Code: 
dev.xhci.0.%desc: Intel Panther Point USB 3.0 controller

EDIT:
fstab:

Code: 
/dev/ufs/KINGSTON32a /mnt/flash     ufs     rw,failok,sync  0       0
Yes, there is sync option, but i still have to type sync after cp anyway or files wont get copied completely.

My formatting routine:
Code: 
dd if=/dev/zero of=/dev/da0 bs=2M count=1 ; sync
gpart create -s BSD /dev/da0
gpart add -t freebsd-ufs /dev/da0
newfs -L KINGSTON32 /dev/da0

tunefs output:
Code: 
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 disabled
tunefs: soft update journaling: (-j)                       disabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: space to hold for metadata blocks: (-k)            6408
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)                                 KINGSTON32
 
Last edited by a moderator:
Phishfry said:
It would help to show the full output when you hotplug this stick.

Do you see the same effects when you use the USB2 ports?
Click to expand...
Its same situation with USB 2.0.

dmesg output:
Code: 
ugen0.3: <Kingston DataTraveler 3.0> at usbus0
umass0 on uhub1
umass0: <Kingston DataTraveler 3.0, class 0/0, rev 3.10/0.01, addr 3> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0xc100
umass0:3:0: Attached to scbus3
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device
da0: Serial Number E0D55EA53584F3C0788C02FE
da0: 400.000MB/s transfers
da0: 29510MB (60437492 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
 
Last edited by a moderator:
usb sticks write performance sucks ass (true for sd cards too) especially for small writes
there are larger capacity usb sticks which are in fact full blown ssds which perform ok (they are also a lot more expensive than the std/slow ones)
i have one which has 200MB/s reads and a10MB/s writes (performance measured with dd) (not the ssd type but advertised as "USB 3.2")
 
What I wonder if a quirk is being applied when it doesn't need to be.
Try disabling this and retest.

da0: quirks=0x2<NO_6_BYTE>
 
5 years ago I bought 2 USB key Kingston model DataTraveler 16G, both were pretty slow and both died something like 3 month after I bought them.
Couldn't mount or format them, I tried few tools, nothing worked both keys were just dead, the product is so bad I didn't even bother with RMA and I put them in a box where they still are ...
Overall I had 4 USB keys from Kingston, they all died in a short period of time.
Since I didn't buy any USB key from them and switched to Sandisk.
While their product aren't bullet proof either, the speed writing is as good as expected and in most cases I still use them after few years.

ayleid96 said:
Yes, there is sync option, but i still have to type sync after cp anyway or files wont get copied completely.
Click to expand...
TBH I still type the sync command after any operation on an usb key, just in case.
 
I was told (as I'm really unfamiliar with this part of the OS) that FreeBSD implements the Bulk-Only transport and does NOT implement the USB Attached SCSI transport introduced in USB 3.0, which could explain the low transfer rates.
 
I have removed sync mount option from /etc/fstab and added noatime. And the results are good, i thought that command sync does exactly the same thing as mount option but i was apparently wrong. I was afraid to umount before sync in fear of data loss but umount just wont let me until all buffers are empty, on linux that is not the case and i poorly assumed that freebsd works the same.

Situation following, with pure linear byte stream:
dd if=/dev/zero of=/dev/da0 bs=2M gives me 27 Megabytes per second, really good in my opinion.
dd if=/dev/da0 of=test bs=2M gives me aroung 55 Megabytes per second, also good for home use.

So after formatting flash drives BSD/UFS the situation is following, allocating data is slower of course:
Copying files over gives me about 15 Megabytes per second on average.
Reading is probably okay i didn't benchmarked it.

Also interestingly enough when cp finished copying files i typed sync and it finished immediately.

There were unpleasant situations when i copied some documents couple of years ago on ext4 formatted drives and took it on trip, when i plugged into laptop and mounted files were not there, and i was on train...

So the problem is solved, thank you everybody for your time and effort.
 
ayleid96 said:
I was afraid to umount before sync in fear of data loss but umount just wont let me until all buffers are empty, on linux that is not the case and i poorly assumed that freebsd works the same.
Click to expand...
The conceptual model for file systems on Linux is the same as FreeBSD.

Both systems use kernel I/O buffers that must be flushed before a file system can be taken from service.

The sync(8) command explicitly flushes all the kernels disk I/O buffers .

The umount(8) command implicitly flushes the kernels disk I/O buffers allocated to the file system being unmounted.

Edit: Just to be perfectly pedantic for those who follow, you must always umount(8) a file system before taking it from service. It's not enough to just issue a sync(8), because the super block(s) for the file system will always be cached, and writing them out is the penultimate act the kernel performs when un-plumbing a file system.
 
gpw928 said:
The conceptual model for file systems on Linux is the same as FreeBSD.

Both systems use kernel I/O buffers that must be flushed before a file system can be taken from service.

The sync(8) command explicitly flushes all the kernels disk I/O buffers .

The umount(8) command implicitly flushes the kernels disk I/O buffers allocated to the file system being unmounted.

Edit: Just to be perfectly pedantic for those who follow, you must always umount(8) a file system before taking it from service. It's not enough to just issue a sync(8), because the super block(s) for the file system will always be cached, and writing them out is the penultimate act the kernel performs when un-plumbing a file system.
Click to expand...
Last time i used linux in home was about 3 years ago, i ran gentoo and rhel 7 and i swear i could umount without sync wherever i wanted.
 
ayleid96 said:
Last time i used linux in home was about 3 years ago, i ran gentoo and rhel 7 and i swear i could umount without sync wherever i wanted.
Click to expand...
That's consistent with what I said above, and absolutely correct for all Unix varieties and emulators because:
gpw928 said:
The umount(8) command implicitly flushes the kernels disk I/O buffers allocated to the file system being unmounted.
Click to expand...
i.e. umount does an implicit sync for the file system being unmounted.
 
You must log in or register to reply here.
Back
Top