linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Szabolcs Szakacsits <szaka@tuxera.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Matthew Wilcox <willy@infradead.org>,
	"Leonidas P. Papadakos" <papadakospan@gmail.com>,
	Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
	<zajec5@gmail.com>, "Darrick J. Wong" <djwong@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: NTFS testing (was: [GIT PULL] vboxsf fixes for 5.14-1
Date: Sat, 4 Sep 2021 00:17:20 +0300	[thread overview]
Message-ID: <alpine.DEB.2.20.2109032152440.61958@tuxera.com> (raw)
In-Reply-To: <YTJf4lBjnliqhI4D@sol.localdomain>


On Fri, 3 Sep 2021, Eric Biggers wrote:
> On Fri, Sep 03, 2021 at 01:09:40AM +0300, Szabolcs Szakacsits wrote:
> > User space drivers can have major disadvantages for certain workloads 
> > however how relevant are those for NTFS users? Most people use NTFS for 
> > file transfers in which case ntfs-3g read and write speed is about 15-20% 
> > less compared to ext4. For example in some quick tests ext4 read was 
> > 3.4 GB/s versus ntfs-3g 2.8 GB/s, and write was 1.3 GB/s versus 1.1 GB/s.
> 
> Your company's own advertising materials promoting your proprietary NTFS driver
> (https://www.tuxera.com/products/tuxera-ntfs-embedded) claim that NTFS-3G is
> much slower than ext4:

Thank you for pointing this out. And please do so whatever else you think 
is not right.

Let's see in detail.

> 	Read:
> 		NTFS-3G: 63.4 MB/s
> 		ext4: 113.8 MB/s
> 		"Microsoft NTFS by Tuxera": 116 MB/s
> 
> 	Write:
> 		NTFS-3G: 16.3 MB/s
> 		ext4: 92.4 MB/s
> 		"Microsoft NTFS by Tuxera": 113.3 MB/s

The page says under the benchmark:

 "Tested on ARM Cortex-A15 Processor / 512 MB RAM / Samsung SSD 840 PRO 256 GB, 
  USB 3.0 / Windows client and Samba over 1 GbE. Actual performance may 
  vary based on software and hardware used."

My quoted benchmark was done on 

 System on Chip: 11th Gen Intel(R) Core(TM) i5-11400 @2.60GHz (12 cores) 
	in ASUSTeK COMPUTER INC. PRIME B560-PLUS motherboard
 OS: Linux 5.10.0-8-amd64 x86_64
 Storage: Samsung SSD 970 PRO 512GB 512GB NVMe
 NTFS-3G 2017.3.23AR.6 (February 1, 2021) integrated FUSE 28 
 ext4 Intree (Linux 5.10.0-8-amd64)
 
> I'm not sure why anything you say should have any credibility 

Please don't believe me and do your own check. Both Ted's logs and the 
performance results which I have shared.

> when it contradicts what your company says elsewhere, 

The text says "Actual performance may vary based on software and hardware 
used." I'm afraid my results don't contradict. Hardware is vastly 
different, software is vastly different:

- The PC is much more powerful. Much faster multi-core CPU, RAM, 
interconnect, and storage compared to an apparently single core Cortex-A15.

- The embedded test used user space Samba, the other one didn't. Samba and 
ntfs-3g competed for one core which made the speed lower than it could have 
been. ksmbd will help a lot on this, just like ntfs3 for samba. And ntfs-3g 
could be also improved a lot, as I mentioned earlier. Isn't it great there 
are so many options?

- Today embedded often has multi-core, so the speed difference is (much) less.

- Tested embedded ntfs-3g version is unknown but it seems to be a (quite) 
old one. My test used one of the latest ones. NTFS-3G performance has 
been improving in time.

- I'm sure the embedded test didn't use the big_writes mount option. 
Otherwise I think the speed could have been around 50 MB/s. Which is still 
not great but at least 3 times faster. We explained and addressed this in 
the latest release note:

https://lore.kernel.org/linux-fsdevel/d343b1d7-6587-06a5-4b60-e4c59a585498@wanadoo.fr/

Overall, you had a good point. That comparison is not the most up-to-date 
one. We will work on it or just remove it.

> and your company has a vested interest in not having proper NTFS support 
> upstreamed

Please explain what you mean exactly by "proper"? 

Linus wrote "does indeed work reasonably well" except the horrible 
performance which was based on misinterpreting test results ntfs-3g being 
4 times slower when in fact it was 21% faster.

If "proper" means being in the kernel then I explained in my previous email 
why we chose FUSE.

> to compete with their proprietary driver.

The proprietary version enables us to pay people working on the open source 
version. The source code is available, anybody could do it. 

> (Note that Tuxera doesn't provide much support for NTFS-3G; most of their 
> efforts are focused on their proprietary driver.)

We provide both commercial and free support for NTFS-3G. We had annually at 
least one stable open source release since 2006, full changelog:

	https://github.com/tuxera/ntfs-3g/releases

And all questions and issues are answered, resolved:

	https://sourceforge.net/p/ntfs-3g/mailman/ntfs-3g-devel/

Thank you Eric again for the very honest feedback.

Best regards,

	Szaka

  reply	other threads:[~2021-09-03 21:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 10:45 Hans de Goede
2021-07-13 19:15 ` Linus Torvalds
2021-07-13 20:14   ` Al Viro
2021-07-13 20:18     ` Al Viro
2021-07-13 20:24       ` Randy Dunlap
2021-07-13 20:32         ` Al Viro
2021-07-13 21:43           ` Randy Dunlap
2021-07-14 10:50     ` Rafał Miłecki
2021-07-14 14:13       ` Christoph Hellwig
2021-07-14 14:51       ` Greg KH
2021-07-14 15:59         ` Rafał Miłecki
2021-07-14 16:05           ` Matthew Wilcox
2021-07-14 16:18             ` Rafał Miłecki
2021-07-15 21:50               ` Neal Gompa
2021-07-16 11:46               ` Leonidas P. Papadakos
2021-07-16 18:07                 ` Linus Torvalds
2021-07-30 15:55                   ` Konstantin Komarov
2021-07-30 17:23                     ` Paragon NTFSv3 (was Re: [GIT PULL] vboxsf fixes for 5.14-1) Linus Torvalds
2021-08-13 16:11                       ` Konstantin Komarov
2021-08-15 20:32                         ` Stephen Rothwell
2021-08-16  3:00                         ` Kari Argillander
2021-09-02 21:55                       ` Linus Torvalds
2021-08-03 22:48                   ` [GIT PULL] vboxsf fixes for 5.14-1 Theodore Ts'o
2021-08-03 23:44                     ` Matthew Wilcox
2021-08-04  0:04                       ` Theodore Ts'o
2021-08-04  0:10                         ` Linus Torvalds
2021-08-04  0:49                           ` Theodore Ts'o
2021-08-04  1:03                             ` Darrick J. Wong
2021-08-04  6:38                               ` Kari Argillander
2021-08-04 16:30                                 ` Theodore Ts'o
2021-08-05 15:48                               ` Konstantin Komarov
2021-08-10  7:02                                 ` Darrick J. Wong
2021-09-02 22:09                           ` NTFS testing (was: " Szabolcs Szakacsits
2021-09-03 17:48                             ` Eric Biggers
2021-09-03 21:17                               ` Szabolcs Szakacsits [this message]
2021-07-17 16:47                 ` Pali Rohár
2021-07-14 16:13           ` Darrick J. Wong
2021-07-14 16:18             ` Christoph Hellwig
2021-07-14 16:38               ` Gao Xiang
2021-07-14 20:03               ` Eric W. Biederman
2021-07-15 22:14               ` Darrick J. Wong
2021-07-13 19:17 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.2109032152440.61958@tuxera.com \
    --to=szaka@tuxera.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=djwong@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=papadakospan@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=zajec5@gmail.com \
    --subject='Re: NTFS testing (was: [GIT PULL] vboxsf fixes for 5.14-1' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).