On Tue, 25 Jul 2006, Yuval Fledel wrote:
> [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).
The kernel driver does not create sparse files at all. 66 seconds to
create a sparse file? Ouch. And how did it know to create a sparse file?
I hope it is not scanning all incoming data for zeroes? That would slow
it down like hell. No other file system does that... The only way sparse
regions are created by doing "lseek(past end of file)+write()".
> 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
And how about with the kernel driver as destination? (Just do "touch
destination" mounting with ntfs-3g, then unmount, mount with kernel driver
and do the copy.)
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
|