Hi,
I downloaded an 2,7 GB ISO image and copied to a pen drive formatted as ext2. The copying progress started with a write speed of 3 MB/s and went slower and slower and ended with a write speed of 627 KB/s.
The copy process took me 47 minutes and I decided to test the write speed of Debian GNU/Linux 8. I tried copying the same file and the copy process started with a write speed of 30 MB/s and ended with 7 MB/s ~ 6 MB/s and the copy process took 9.5 minutes.

Why is the write speed of the pen drive so slow on FreeBSD?
 
You forgot a tag in your tag list, didn't you? lacks systemd, bad, bad kernel stay with linux, ..."
 
Hi,
I downloaded an 2,7 GB ISO image and copied to a pen drive formatted as ext2. The copying progress started with a write speed of 3 MB/s and went slower and slower and ended with a write speed of 627 KB/s.
The copy process took me 47 minutes and I decided to test the write speed of Debian GNU/Linux 8. I tried copying the same file and the copy process started with a write speed of 30 MB/s and ended with 7 MB/s ~ 6 MB/s and the copy process took 9.5 minutes.

Why is the write speed of the pen drive so slow on FreeBSD?
According to the Wiki (https://wiki.freebsd.org/Ext2fs/) ext2fs(5) defaults to synchronous mode which might be slower. Try adding the async option when you mount your pen drive. Linux uses async mode by default.
 
Seems like I've read about Linux using write caching or delayed writes without being obvious about it. Maybe only on USB, I don't recall.

The speed still seems way too low on FreeBSD. What was the exact command used? In other words, did it use a reasonable buffer?
 
So it was not dd(1). Oh, I see. You are using ext2 on the USB drive. I don't have any idea whether the FreeBSD implementation performs well, but that would be my first guess. Copying the same file to the same USB device which has been formatted with UFS would be a good test.
 
For comparison using UFS make sure you test with both soft updates on and off. I bet you'll see the same bad performance when soft updates are off. See tunefs(8) on how to turn on/off softupdates.
 
I tried mounting with -o async but it is still very slow.

I will try to format to UFS, but that's not a solution for me, since I'm using this pen drive on FreeBSD and on Debian, and Linux does not support UFS very well.

Thanks in advance.
 
Hi,
I formatted the pen drive to UFS and set the soft updates journaling on, but it is still much slower than ext2fs on Linux. When I tried to copy the same file to the pen drive, the write speed varied between 3 MB/s ~ 4.6 MB/s, very slow compared to Linux. Every time that I try to copy a big file on FreeBSD, the whole system slows down.
So what can this sluggishness be?
 
So, is your pen drive detected as usb1 or usb2? Is there a difference on FreeBSD vs. Linux?
There are lots of possible variables here. When you have checked all of them, you will probably find out why the speed differs.
 
Hi,
I formatted the pen drive to UFS and set the soft updates journaling on, but it is still much slower than ext2fs on Linux. When I tried to copy the same file to the pen drive, the write speed varied between 3 MB/s ~ 4.6 MB/s, very slow compared to Linux. Every time that I try to copy a big file on FreeBSD, the whole system slows down.
So what can this sluggishness be?
This obviously shouldn't happen. You might take a look at your dmesg(8) output and /var/log/messages to see if there are any related interrupt or controller related messages while copying the file.

It could be a controller issue or interrupt storm pegging the CPU during the copy. It's hard to say without knowing more.
 
dmesg:
Code:
ext2fs: da0s1: wrong magic number 0 (expected 0xef53)
ext2fs: da0s1: wrong magic number 0 (expected 0xef53)
This is probably a problem.
Thanks.
 
Write caching is possible on FreeBSD?
How can I do write faster?

Use Linux only to copy a big file to a USB stick is not the best solution.

Sorry I am a newbie to FreeBSD.



Thanks for responses.
 
There are command-line buffering programs, although I can't recall a specific one right now. The problem with this, and with write-caching in general, is that the command appears to finish, but the write is still continuing in the background. If the user removes the memory stick before the write is actually complete, data will be corrupted.
 
There are command-line buffering programs, although I can't recall a specific one right now. The problem with this, and with write-caching in general, is that the command appears to finish, but the write is still continuing in the background. If the user removes the memory stick before the write is actually complete, data will be corrupted.

Does Linux suffer from this problem?
If I write a file to a stick and remove before the data is flushed, the data will be corrupted?
 
That is what I recall, but I don't recall the details. So it might be only certain versions or distributions. And I might have it wrong. That happens sometimes.
 
Many pen drives do have a LED signaling the activity. In my experience with different OS, one should be save, removing the stick once the LED stops flashing for let's say more than 15 seconds, after issuing umount.
 
A write cache will not make the data be saved faster to the USB flash media. All it will do is make the command complete faster and free up the CLI, but the data will still be saved at the same speed.
 
Thank UnixRocks.

So write-caching is not an advantage or something possible in FreeBSD.

That's what I thought initially, but I have the need to hear the obvious when I'm learning something new (although I feel comfortable with Linux, FreeBSD is quite different and I'm reading the Handbook yet).
 
FreeBSD does use write caching and it works just perfectly on UFS and ZFS. However, unlike on Linux the disk devices (such as /dev/ada0) do not implement any kind of caching/buffering themselves and it's left to the filesystem drivers to implement the kind of caching/buffering they prefer. It's very likely that the ext2 driver in FreeBSD could use some improvements in this area.
 
Back
Top