Re: [GIT PULL] vboxsf fixes for 5.14-1

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Aug 04, 2021 at 09:38:10AM +0300, Kari Argillander wrote:
> Konstantin has wrote about these thing see below.
> 
> Source:
> https://lore.kernel.org/linux-fsdevel/7538540ab82e4b398a0203564a1f1b23@paragon-software.com/

Thanks for the link; that's really helpful.

> I'm just bringing this thing up because so many has asked and Konstantin
> has not responded recently. Hopefully he will soon. Of course is it
> little bit worrying that example generic/013 still fails after almoust
> year has passed and Konstantin said he is working on it. And it seems that
> more tests fails than beginning of review process.

Also interesting is that back in August 2020 Konstantin had promised
that they would be publishing their own fsck and mkfs tools.
Personally, I consider having a strong set of file system utilities to
be as important, if not more important, than the kernel code.  Perhaps
there are licensing issues which is why he hasn't been able to make
his code available?

One thing which I wonder about is whether there is anyone other than
Konstantin which is working on ntfs3?  I'm less concerned about
specific problems about the *code* --- I'll let folks like Christoph,
Dave, and Al weigh in on that front.

I'm more concerned about the long term sustainability and
maintainibility of the effort.  Programming is a team sport, and this
is especially true in the file system.  If you look at the successful
file systems, there are multiple developers involved, and ideally,
those developers work for a variety of different companies.  This way,
if a particular file system developer gets hit by a bus, laid low with
COVD-19, or gets laid off by their company due to changing business
strategies, or just decides to accept a higher paying job elsewhere,
the file system can continue to be adequately supported upstream.

If Konstantin really is the only developer working on ntfs3, that may
very well explain why generic/013 failures have been unaddressed in
over a year.  Which is why I tend to be much more concerned about
development community and development processes than just the quality
and maturity of the code.  If you have a good community and
development processes, the code qualtiy will follow.  If you don't,
that tends to be a recipe for eventual failure.

There are a large number of people on the cc line, include from folks
like Red Hat, SuSE, etc.  It would be *great* to hear that they are
also working on ntfs3, and it's not just a one engineer show.  (Also,
given the deadlock problems, lack of container compatibility, etc.,
are the Linux distros actually planning on shipping ntfs3 to their
customers?  Are they going to help make ntfs3 suitable for customers
with access to their help desks?)

> > > I can even give them patches and configs to make it trivially easy for
> > > them to run fstests using KVM or GCE....

I've since posted RFC patches to the fstests list to allow other
people to run xfstests on ntfs3.  I don't know why Konstantin hadn't
published his patches to fstests a year ago --- perhaps because of
licensing concerns with the mkfs and fsck userspace programs which
Paragon Software is using?

My fstests patches use the mkfs.ntfs and ntfsfix which ships with the
ntfs-3g package.  They are not ideal; for example ntfsfix will not
detect or fix all problems, and it is documented that for some issues,
you have to boot into Windows and run CHKDSK.  But it is the only
thing that is going to be available for any **users** of ntfs3 outside
of Paragon Software.

Some kind of update from Paragon Software about when their versions of
{mkfs,fsck}.ntfs might be made available for Linux distributions to
use would certainly be enlightening.

					- Ted