|
From: Anton A. <ai...@ca...> - 2006-08-15 07:52:37
|
On Tue, 2006-08-15 at 02:56 +0300, Szakacsits Szabolcs wrote:
> On Tue, 15 Aug 2006, Anton Altaparmakov wrote:
> > And if that is all you are planning than no thanks. It is a completely
> > unnecessary performance hit I am not willing to take. If you still think
> > I am misunderstanding you then you will have to give a lot more details
> > than that email you reference above so I can understand what you mean...
>
> Talk, talk, talk just because you keep misunderstanding and confusing
> things. How about some work getting done? For this year this is the commit
> statistic:
>
> 443 szaka (including index code)
> 52 yura
> 39 antona
> 5 uvman
>
> I think you barely do anything else just setting back the project for quite
> a while. I really hope you don't do this intentionally.
What does the above say? Nothing. I have been working on the kernel
drivers for Linux and OSX and neither of those are public at present so
you have no idea how many commits I would have if you add those up.
Anyway there wouldn't be many as for Linux I am not doing any commits -
just working in a local directory without source control and for OSX I
just commit once a week or so as a form of backup mechanism rather than
anything else. That doesn't change the fact that my diff between the
current kernel driver and the modified kernel driver currently is at
751kiB according to diff stat containing 11834 insertions and 3054
deletions and the OSX kernel driver is currently as 23327 lines (counted
with "wc -l"). So I have worked on over 35 thousand lines of code since
going behind closed doors... And note that some of the serious bug
fixes in the Linux kernel driver I asked for permission to submit to the
mainstream kernel and I was allowed to do it. Pretty much the entirety
of the last one or two NTFS kernel driver releases are based on this
work behind closed doors. So it is not like the public is not
benefiting from my work already...
How many lines of code have you done? That's a true measure of how much
work has been done... Commits are totally meaningless in comparison...
I can have hundreds/thousands of commits if I were to commit every
little tiny thing I do but given I am working by myself and don't need
to submit small patches for review to anyone yet I don't bother and just
do lots of work instead.
Anyway this is not a pissing contest so lets stop this here!
All of us want that this project succeeds and I believe we all want that
just the same.
But please don't tell me I am holding the project back. In my opinion I
am taking it forward massively but you can't see that until it is all
released and everyone can then benefit at once fully. It may not be how
you like doing things and I would prefer to just be able to release
everything I do but it is better this way than if I didn't do it at all.
I certainly don't see anyone else doing the needed kernel work...
And yes you think FUSE will work as well as the kernel driver but I
don't agree and in the end when both drivers are complete we can
benchmark them against each other and then we will see. (-: I am sure
both drivers will have good and bad points and both will be able to
merge things from each other to make them even faster...
I still believe that only kernel drivers are really useful as a user
space driver couldn't for example be a root file system (I may be wrong
and it may be possible to do it somehow using an initrd or something - I
have never tried but it certainly is more work then just having a kernel
module to load or even built into the kernel) and also I do not believe
that FUSE can ever be as fast as a kernel implementation.
And I don't think the performance numbers you showed mean that much as
such. If you compared the exact same file system implementation once in
the kernel and once in user space I bet you you would see a difference
in favour of the kernel (certainly last week when I was in California I
heard very different numbers to yours when comparing e.g. ext3 in-kernel
and ex-kernel through FUSE on Linux). Also your numbers are meaningless
because ntfsmount/-3g are single threaded whereas all other drivers you
compared against are multithreaded so the moment you would run a
multithreaded benchmark ntfsmount/-3g would immediately suck _really_
badly performancewise. Imagine "updatedb" running whilst you are trying
to get some work done on the same ntfs partition. That will probably be
quite an unpleasant experience I would imagine unless your CPU is very
very fast and you have tons of ram in which case it might be all not too
bad but it probably still won't be very nice...
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 / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
