benta...@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@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
