[OpenIndiana-discuss] USB 2 performance

[Jonathan Adams]

I know it's a little off-topic, but have you thought of creating a zpool on
the USB stick and seeing how that goes?

ZFS on Linux works well for removable media, assuming you can "sudo zpool
import"

Jon

PS. I generally end up dd'ing with a block size of 4M to get maximum
throughput.

On 30 July 2015 at 15:17, Jean-Pierre André <jean-pierre.andre at wanadoo.fr>
wrote:

> bentahyr at chez.com wrote:
>
>> Hi Jean-Pierre,
>>
>> I was using 2012.1.15AR.8 from SFE, with no specific option for mount
>> command :
>> # ntfs-3g -o uid=101 /dev/dsk/c2t0d0p1 /mnt
>>
>> Since then I switched to the last version available on your website
>> (2015.3.14AR.1), and redid the test, still using the same mount command.
>> $ dd if=FreeDOS-1.1-memstick-2-2048M.img
>> of=/mnt/FreeDOS-1.1-memstick-2-2048M.img
>> 1412712+0 records in
>> 1412712+0 records out
>> 723308544 bytes (723 MB) copied, 2552.51 s, 283 kB/s
>> I stopped it as it wasn't necessary to wait 3h
>>
>> $ dd if=FreeDOS-1.1-memstick-2-2048M.img
>> of=/mnt/FreeDOS-1.1-memstick-2-2048M.img bs=4096
>> 166643+0 records in
>> 166643+0 records out
>> 682569728 bytes (683 MB) copied, 2360.02 s, 289 kB/s
>> Stopped as well
>>
>> Mount with big_writes option
>> # ntfs-3g -o big_writes,uid=101 /dev/dsk/c2t0d0p1 /mnt
>>
>
> The big_writes option is not supported by the fuse variant
> for OpenIndiana.
>
> $ dd if=FreeDOS-1.1-memstick-2-2048M.img
>> of=/mnt/FreeDOS-1.1-memstick-2-2048M.img bs=4096
>> 207578+0 records in
>> 207578+0 records out
>> 850239488 bytes (850 MB) copied, 3691.7 s, 230 kB/s
>> Stopped as well
>>
>> Now I format the disk on Win7 to NTFS, 512b rather than defaulting to
>> 4096b
>> $ dd if=FreeDOS-1.1-memstick-2-2048M.img
>> of=/mnt/FreeDOS-1.1-memstick-2-2048M.img
>> 172937+0 records in
>> 172937+0 records out
>> 708349952 bytes (708 MB) copied, 2367.44 s, 299 kB/s
>> Stopped as well
>>
>> I don't really know what to blame, maybe the FUSE stage might the
>> bottleneck here.
>>
>
> ntfs-3g has never been efficient on bulk transfers because
> it is organized on top of fuse, but there must be another
> explanation for this very bad throughput.
>
> I have no idea why, ATM.
>
> Regards
>
> Jean-Pierre
>
> Maybe dd is not really the good command to test this as well.
>> I wanted to test exFAT as weel but I'm running out of time before going
>> off until September.
>>
>> Ben
>>
>
>
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>