LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
To: "dsterba@suse.cz" <dsterba@suse.cz>
Cc: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: RE: [PATCH] fs: NTFS read-write driver GPL implementation by Paragon Software.
Date: Thu, 20 Aug 2020 10:48:49 +0000
Message-ID: <a8fa5b2b31b349f2858306af01269eda@paragon-software.com> (raw)
In-Reply-To: <20200815190642.GZ2026@twin.jikos.cz>

From: David Sterba <dsterba@suse.cz>
Sent: Saturday, August 15, 2020 10:07 PM
> 
> 1. check existing support in kernel
> 
> There is fs/ntfs with read-only support from Tuxera, last change in the
> git tree is 3 years ago. The driver lacks read-write support so there's
> not 100% functionality duplication but there's still driver for the same
> filesystem.
> 
> I don't know what's the feature parity, how much the in-kernel driver is
> used (or what are business relations of Tuxera and Paragon), compared to
> the FUSE-based driver, but ideally there's just one NTFS driver in linux
> kernel.
> 
> The question I'd ask:
> 
> - what are users of current fs/ntfs driver going to lose, if the driver
>   is going to be completely replaced by your driver
> 
>   If the answer is 'nothing' then, the straightfowrad plan is to just
>   replace it. Otherwise, we'll have to figure that out.

Hi! Regarding the comparison with fs/ntfs driver - we of course did the analysis. There are two main points which make the difference: full read-write support (including compressed/sparse files) and journal replaying. The one thing which is missing in fs/ntfs3 in the inital patch is the appropriate processing of hybernated volumes (mounting them read-only to avoid corruptions). This, however, is considered as trivial change and will be added either in v2, or in v3. In general, we want to have the community's feedback on the topic, and if it's more suitable for the Linux Kernel not to have two implementations in Kernel, then the 'fs/ntfs' may be replaced.  

> 
> 2. split the patch
> 
> One patch of 27k lines of code is way too much to anybody to look at.

The patch will be splitted in v2 file-wise. Wasn't clear initially which way will be more convenient to review.

> 3. determine support status
> 
> You state intentions to work on the driver and there's a new entry in
> MAINTAINERS file with 'Supported', so that's a good sign that it's not
> just one-time dump of code. Fixing bugs or adding functionality is
> expected.
> 
> 4. development git tree
> 
> Once the filesystem is merged, you'd be getting mails from people
> running eg. static checkers, build tests, sending cleanups or other
> tree-wide changes.  The entry in MAINTAINER file does not point to any
> git tree, so that's not clear to me what's the expected way to get the
> fixes to Linus' tree or where are people supposed to look for 'is this
> fixed already'.

The external git repo for the code is currently being prepared, so it's the matter of time to have it. Will add the appropriate links to the MAINTERS once done.


  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-14 12:29 Konstantin Komarov
2020-08-14 13:17 ` Nikolay Borisov
2020-08-14 13:40 ` David Sterba
2020-08-20  9:26   ` Konstantin Komarov
2020-08-20 10:59   ` Konstantin Komarov
2020-08-14 14:08 ` Aurélien Aptel
2020-08-20 10:20   ` Konstantin Komarov
2020-08-14 15:30 ` Aurélien Aptel
2020-08-20 10:38   ` Konstantin Komarov
2020-08-15 19:06 ` David Sterba
2020-08-16  0:42   ` Matthew Wilcox
2020-08-20 10:48   ` Konstantin Komarov [this message]
2020-08-16  7:56 ` Pali Rohár

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=a8fa5b2b31b349f2858306af01269eda@paragon-software.com \
    --to=almaz.alexandrovich@paragon-software.com \
    --cc=dsterba@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git