|
From: Yuval F. <yu...@gm...> - 2006-07-24 21:02:05
|
[Moving a discussion that started on the forum to the mailing list. Both because the discussion is now more technical, and because I attached a file] On 7/24/06, AntonA wrote: > I mean yes, the runlist lookups are pretty inneficient but they are not > _that_ inefficient and it should not cause such slowdown. Same for the > allocator it should not make a difference like this... After profiling ntfs-3g-20070714, the problem is actually building the runlist (profiling output attached). Anyone interested in picking up the glove? > For comparison using the kernel ntfs driver (Linux) and doing just a dd > like so: > > date && time dd if=/dev/zero of=test-big-file count=1 bs=1G && date > > Gives me: > > Mon Jul 24 19:49:58 BST 2006 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB) copied, 27.2384 seconds, 39.4 MB/s > > real 0m27.242s > user 0m0.000s > sys 0m7.460s > Mon Jul 24 19:50:25 BST 2006 > > So it took only 27 seconds... Unless the kernel driver is not creating sparse files, this is not a good comparison. ntfs-3g on my laptop did the same micro-benchmark in 66 seconds. The output file was indeed 1GB, but took on disk 0 bytes (not counting metadata). For comparison, coping a large file from one ntfs partition mounted using the kernel driver to another ntfs partition mounted using ntfs-3g copied ~142MB in 5:19 minutes. (actual size on disk: 134MB): real 5m18.255s user 0m0.028s sys 0m0.728s -- Yuval Fledel |
