Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
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.
Thread-Topic: [PATCH] fs: NTFS read-write driver GPL implementation by Paragon
 Software.
Thread-Index: AdZyNcmjSkpkGje7R9K6YobJrVDyZwA6EcIAAPAHtmA=
Date:   Thu, 20 Aug 2020 10:48:49 +0000
Message-ID: <a8fa5b2b31b349f2858306af01269eda@paragon-software.com>
References: <2911ac5cd20b46e397be506268718d74@paragon-software.com>
 <20200815190642.GZ2026@twin.jikos.cz>
In-Reply-To: <20200815190642.GZ2026@twin.jikos.cz>
Accept-Language: ru-RU, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: David Sterba <dsterba@suse.cz>
Sent: Saturday, August 15, 2020 10:07 PM
>=20
> 1. check existing support in kernel
>=20
> 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.
>=20
> 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.
>=20
> The question I'd ask:
>=20
> - what are users of current fs/ntfs driver going to lose, if the driver
>   is going to be completely replaced by your driver
>=20
>   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 ana=
lysis. 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 corrupti=
ons). This, however, is considered as trivial change and will be added eith=
er 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. =20

>=20
> 2. split the patch
>=20
> 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 wa=
y will be more convenient to review.

> 3. determine support status
>=20
> 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.
>=20
> 4. development git tree
>=20
> 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.