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@xxxxxxxxxxxxxxxxxxxx/ 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
