2021-07-13 10:48:45

by Hans de Goede

[permalink] [raw]
Subject: [GIT PULL] vboxsf fixes for 5.14-1

Hi Linus,

Here is a pull-req with a set of patches fixing a vboxsf bug for 5.14
(I am the vboxsf maintainer).

Linus, sorry for sending this directly through you, instead of going
through some other tree, but trying to get this upstream through the
linux-fsdevel list / patch-review simply is not working.

This bugfix patch-set (3 preparation patches + 1 actual bugfix) fixes
a bug which is actually being hit by users in the wild, e.g. doing
a "git clone" on a vbox guest inside a shared-folder will fail
without his fix. Since you merge pull-req-s for a bunch of other
filesystems directly I'm hoping that you are willing to take this
one too.

This patch-set has been posted on the linux-fsdevel for the first
time on January 21th 2021, so almost 6 months ago and I've send
out several pings and a resend since then, but unfortunately
no-one on the linux-fsdevel list seems to have interest in /
time for reviewing vboxsf patches.

Regards,

Hans


The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:

Linux 5.13-rc1 (2021-05-09 14:17:44 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git tags/vboxsf-v5.14-1

for you to fetch changes up to 52dfd86aa568e433b24357bb5fc725560f1e22d8:

vboxsf: Add support for the atomic_open directory-inode op (2021-06-23 14:36:52 +0200)

----------------------------------------------------------------
Signed tag for a set of bugfixes for vboxsf for 5.14

This patch series adds support for the atomic_open
directory-inode op to vboxsf.

Note this is not just an enhancement this also fixes an actual issue
which users are hitting, see the commit message of the
"boxsf: Add support for the atomic_open directory-inode" patch.

----------------------------------------------------------------
Hans de Goede (4):
vboxsf: Honor excl flag to the dir-inode create op
vboxsf: Make vboxsf_dir_create() return the handle for the created file
vboxsf: Add vboxsf_[create|release]_sf_handle() helpers
vboxsf: Add support for the atomic_open directory-inode op

fs/vboxsf/dir.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++--------
fs/vboxsf/file.c | 71 +++++++++++++++++++++++++++++++-------------------
fs/vboxsf/vfsmod.h | 7 +++++
3 files changed, 116 insertions(+), 38 deletions(-)


2021-07-13 19:18:39

by Linus Torvalds

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

On Tue, Jul 13, 2021 at 3:45 AM Hans de Goede <[email protected]> wrote:
>
> Linus, sorry for sending this directly through you, instead of going
> through some other tree, but trying to get this upstream through the
> linux-fsdevel list / patch-review simply is not working.

Well, the filesystem maintainer sending their patches to me as a pull
request is actually the norm rather than the exception when it comes
to filesystems.

It's a bit different for drivers, but that's because while we have
multiple filesystems, we have multiple _thousand_ drivers, so on the
driver side I really don't want individual driver maintainers to all
send me their individual pull requests - that just wouldn't scale.

So for individual drivers, we have subsystem maintainers, but for
individual filesystems we generally don't.

(When something then touches the *common* vfs code, that's a different
thing - but something like this vboxsf thing this pull request looks
normal to me).

Even with a maintainer sending me pull requests I do obviously prefer
to see indications that other people have acked/tested/reviewed the
patches, but this is fairly small, simple and straightforward, and
absolutely nothing in this pull request makes me go "oh, that's
sketchy".

So no need to apologize at all, this all looks very regular.

Linus

2021-07-13 19:18:54

by pr-tracker-bot

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

The pull request you sent on Tue, 13 Jul 2021 12:45:19 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git tags/vboxsf-v5.14-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/40226a3d96ef8ab8980f032681c8bfd46d63874e

Thank you!

--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

2021-07-13 20:26:01

by Randy Dunlap

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

On 7/13/21 1:18 PM, Al Viro wrote:
> On Tue, Jul 13, 2021 at 08:14:04PM +0000, Al Viro wrote:
>> On Tue, Jul 13, 2021 at 12:15:13PM -0700, Linus Torvalds wrote:
>>> On Tue, Jul 13, 2021 at 3:45 AM Hans de Goede <[email protected]> wrote:
>>>>
...
>>>
>>> (When something then touches the *common* vfs code, that's a different
>>> thing - but something like this vboxsf thing this pull request looks
>>> normal to me).
>>
>> To elaborate a bit - there's one case when I want it to go through
>> vfs.git, and that's when there's an interference between something
>> going on in vfs.git and the work done in filesystem.
>
> Example: if there's a series changing calling conventions for some method
> brewing in vfs.git and changes to filesystem's instance of that method
> in the filesystem tree. Then I'd rather it coordinated before either
> gets merged. It might be an invariant branch in either tree pulled by
> both, it might be a straight pull into vfs.git and sorting the things out
> there - depends upon the situation.
>

Hi Al,

Where would you prefer for kernel-doc changes in fs/*.[ch] be merged?

E.g., from June 27:

https://lore.kernel.org/linux-fsdevel/[email protected]/


thanks.
--
~Randy

2021-07-13 20:36:28

by Al Viro

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

On Tue, Jul 13, 2021 at 01:24:06PM -0700, Randy Dunlap wrote:

> Hi Al,
>
> Where would you prefer for kernel-doc changes in fs/*.[ch] be merged?
>
> E.g., from June 27:
>
> https://lore.kernel.org/linux-fsdevel/[email protected]/

Umm... I'd been under impression that kernel-doc stuff in general goes
through akpm, TBH. I don't remember ever having a problem with your
patches of that sort; I can grab that kind of stuff, but if there's
an existing pipeline for that I'd just as well leave it there...

2021-07-13 20:41:26

by Al Viro

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

On Tue, Jul 13, 2021 at 12:15:13PM -0700, Linus Torvalds wrote:
> On Tue, Jul 13, 2021 at 3:45 AM Hans de Goede <[email protected]> wrote:
> >
> > Linus, sorry for sending this directly through you, instead of going
> > through some other tree, but trying to get this upstream through the
> > linux-fsdevel list / patch-review simply is not working.
>
> Well, the filesystem maintainer sending their patches to me as a pull
> request is actually the norm rather than the exception when it comes
> to filesystems.
>
> It's a bit different for drivers, but that's because while we have
> multiple filesystems, we have multiple _thousand_ drivers, so on the
> driver side I really don't want individual driver maintainers to all
> send me their individual pull requests - that just wouldn't scale.
>
> So for individual drivers, we have subsystem maintainers, but for
> individual filesystems we generally don't.
>
> (When something then touches the *common* vfs code, that's a different
> thing - but something like this vboxsf thing this pull request looks
> normal to me).

To elaborate a bit - there's one case when I want it to go through
vfs.git, and that's when there's an interference between something
going on in vfs.git and the work done in filesystem. Other than
that, I'm perfectly fine with maintainer sending pull request directly
to Linus (provided that I hadn't spotted something obviously wrong
in the series, of course, but that's not "I want it to go through
vfs.git" - that's "I don't want it in mainline until such and such
bug is resolved").

2021-07-13 20:42:53

by Al Viro

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

On Tue, Jul 13, 2021 at 08:14:04PM +0000, Al Viro wrote:
> On Tue, Jul 13, 2021 at 12:15:13PM -0700, Linus Torvalds wrote:
> > On Tue, Jul 13, 2021 at 3:45 AM Hans de Goede <[email protected]> wrote:
> > >
> > > Linus, sorry for sending this directly through you, instead of going
> > > through some other tree, but trying to get this upstream through the
> > > linux-fsdevel list / patch-review simply is not working.
> >
> > Well, the filesystem maintainer sending their patches to me as a pull
> > request is actually the norm rather than the exception when it comes
> > to filesystems.
> >
> > It's a bit different for drivers, but that's because while we have
> > multiple filesystems, we have multiple _thousand_ drivers, so on the
> > driver side I really don't want individual driver maintainers to all
> > send me their individual pull requests - that just wouldn't scale.
> >
> > So for individual drivers, we have subsystem maintainers, but for
> > individual filesystems we generally don't.
> >
> > (When something then touches the *common* vfs code, that's a different
> > thing - but something like this vboxsf thing this pull request looks
> > normal to me).
>
> To elaborate a bit - there's one case when I want it to go through
> vfs.git, and that's when there's an interference between something
> going on in vfs.git and the work done in filesystem.

Example: if there's a series changing calling conventions for some method
brewing in vfs.git and changes to filesystem's instance of that method
in the filesystem tree. Then I'd rather it coordinated before either
gets merged. It might be an invariant branch in either tree pulled by
both, it might be a straight pull into vfs.git and sorting the things out
there - depends upon the situation.

2021-07-13 21:45:49

by Randy Dunlap

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

On 7/13/21 1:32 PM, Al Viro wrote:
> On Tue, Jul 13, 2021 at 01:24:06PM -0700, Randy Dunlap wrote:
>
>> Hi Al,
>>
>> Where would you prefer for kernel-doc changes in fs/*.[ch] be merged?
>>
>> E.g., from June 27:
>>
>> https://lore.kernel.org/linux-fsdevel/[email protected]/
>
> Umm... I'd been under impression that kernel-doc stuff in general goes
> through akpm, TBH. I don't remember ever having a problem with your
> patches of that sort; I can grab that kind of stuff, but if there's
> an existing pipeline for that I'd just as well leave it there...
>

Jon Corbet has merged some of them, but I'll be glad to send them to
akpm. Thanks.

{adding Cc: akpm for his info}

2021-07-14 10:53:46

by Rafał Miłecki

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

Hi Alexander,

On 13.07.2021 22:14, Al Viro wrote:
> To elaborate a bit - there's one case when I want it to go through
> vfs.git, and that's when there's an interference between something
> going on in vfs.git and the work done in filesystem. Other than
> that, I'm perfectly fine with maintainer sending pull request directly
> to Linus (provided that I hadn't spotted something obviously wrong
> in the series, of course, but that's not "I want it to go through
> vfs.git" - that's "I don't want it in mainline until such and such
> bug is resolved").

let me take this opportunity to ask about another filesystem.

Would you advise to send pull req for the fs/ntfs3 directly to Linus?

That is a pending filesystem that happens to be highly expected by many
Linux focused communities.


Paragon Software GmbH proved it's commitment by sending as many as 26
versions on it's patchset. The last set was send early April:

[PATCH v26 00/10] NTFS read-write driver GPL implementation by Paragon Software
https://marc.info/?l=linux-fsdevel&m=161738417018673&q=mbox
https://patchwork.kernel.org/project/linux-fsdevel/list/?series=460291


I'd say there weren't any serious issues raised since then.

One Tested-by, one maintenance question, one remainder, one clang-12
issue [0] [1].

It seems this filesystem only needs:
1. [Requirement] Adjusting to the meanwhile changed iov API [2]
2. [Clean up] Using fs/iomap/ helpers [3]


[0] https://marc.info/?t=161738428400012&r=1&w=2
[1] https://marc.info/?t=162143182800001&r=1&w=2
[2] https://marc.info/?l=linux-fsdevel&m=162607857810008&w=2
[3] https://marc.info/?l=linux-fsdevel&m=162152950315047&w=2

2021-07-14 14:16:50

by Christoph Hellwig

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

> That is a pending filesystem that happens to be highly expected by many
> Linux focused communities.

This sounds like generated by a markov chain fed all kinds of marketeer
BS..

Independent of that resending a more than 3 month old page set usually
really helps to get some reviewer attention.

2021-07-14 14:52:35

by Greg Kroah-Hartman

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

On Wed, Jul 14, 2021 at 12:50:08PM +0200, Rafał Miłecki wrote:
> Hi Alexander,
>
> On 13.07.2021 22:14, Al Viro wrote:
> > To elaborate a bit - there's one case when I want it to go through
> > vfs.git, and that's when there's an interference between something
> > going on in vfs.git and the work done in filesystem. Other than
> > that, I'm perfectly fine with maintainer sending pull request directly
> > to Linus (provided that I hadn't spotted something obviously wrong
> > in the series, of course, but that's not "I want it to go through
> > vfs.git" - that's "I don't want it in mainline until such and such
> > bug is resolved").
>
> let me take this opportunity to ask about another filesystem.
>
> Would you advise to send pull req for the fs/ntfs3 directly to Linus?
>
> That is a pending filesystem that happens to be highly expected by many
> Linux focused communities.
>
>
> Paragon Software GmbH proved it's commitment by sending as many as 26
> versions on it's patchset. The last set was send early April:
>
> [PATCH v26 00/10] NTFS read-write driver GPL implementation by Paragon Software
> https://marc.info/?l=linux-fsdevel&m=161738417018673&q=mbox
> https://patchwork.kernel.org/project/linux-fsdevel/list/?series=460291
>
>
> I'd say there weren't any serious issues raised since then.
>
> One Tested-by, one maintenance question, one remainder, one clang-12
> issue [0] [1].
>
> It seems this filesystem only needs:
> 1. [Requirement] Adjusting to the meanwhile changed iov API [2]
> 2. [Clean up] Using fs/iomap/ helpers [3]

Why haven't those things been done and the patches resubmitted for
review? Nothing we can do from our side when the developers don't want
to submit a new series, right?

thanks,

greg k-h

2021-07-14 16:01:37

by Rafał Miłecki

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

On 14.07.2021 16:51, Greg KH wrote:
> On Wed, Jul 14, 2021 at 12:50:08PM +0200, Rafał Miłecki wrote:
>> Hi Alexander,
>>
>> On 13.07.2021 22:14, Al Viro wrote:
>>> To elaborate a bit - there's one case when I want it to go through
>>> vfs.git, and that's when there's an interference between something
>>> going on in vfs.git and the work done in filesystem. Other than
>>> that, I'm perfectly fine with maintainer sending pull request directly
>>> to Linus (provided that I hadn't spotted something obviously wrong
>>> in the series, of course, but that's not "I want it to go through
>>> vfs.git" - that's "I don't want it in mainline until such and such
>>> bug is resolved").
>>
>> let me take this opportunity to ask about another filesystem.
>>
>> Would you advise to send pull req for the fs/ntfs3 directly to Linus?
>>
>> That is a pending filesystem that happens to be highly expected by many
>> Linux focused communities.
>>
>>
>> Paragon Software GmbH proved it's commitment by sending as many as 26
>> versions on it's patchset. The last set was send early April:
>>
>> [PATCH v26 00/10] NTFS read-write driver GPL implementation by Paragon Software
>> https://marc.info/?l=linux-fsdevel&m=161738417018673&q=mbox
>> https://patchwork.kernel.org/project/linux-fsdevel/list/?series=460291
>>
>>
>> I'd say there weren't any serious issues raised since then.
>>
>> One Tested-by, one maintenance question, one remainder, one clang-12
>> issue [0] [1].
>>
>> It seems this filesystem only needs:
>> 1. [Requirement] Adjusting to the meanwhile changed iov API [2]
>> 2. [Clean up] Using fs/iomap/ helpers [3]
>
> Why haven't those things been done and the patches resubmitted for
> review? Nothing we can do from our side when the developers don't want
> to submit a new series, right?

The real issue (broken compilation) has been pointed out 2 days ago and
is a result of a more recent commit. For months filesystem could be
pushed but it wasn't for unknown reason.

As for fs/iomap/ helpers it's unclear to me if that is really required
or could be worked on later as a clean up. Darrick joked his opinion on
using those helper is biased.

In short I'd say: missing feedback.

2021-07-14 16:10:31

by Matthew Wilcox

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

On Wed, Jul 14, 2021 at 05:59:19PM +0200, Rafał Miłecki wrote:
> In short I'd say: missing feedback.

Uh, with all due respect: Fuck you.

I've provided feedback, and Paragon have done a fantastic job of
responding to it. Pretending that the filesystem has simply been
ignored is hugely disrespectful of my time and those at Paragon.

I'm supportive of ntfs3 being included, FWIW. It looks to be
in much better shape than the existing fs/ntfs.

2021-07-14 16:15:32

by Darrick J. Wong

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

On Wed, Jul 14, 2021 at 05:59:19PM +0200, Rafał Miłecki wrote:
> On 14.07.2021 16:51, Greg KH wrote:
> > On Wed, Jul 14, 2021 at 12:50:08PM +0200, Rafał Miłecki wrote:
> > > Hi Alexander,
> > >
> > > On 13.07.2021 22:14, Al Viro wrote:
> > > > To elaborate a bit - there's one case when I want it to go through
> > > > vfs.git, and that's when there's an interference between something
> > > > going on in vfs.git and the work done in filesystem. Other than
> > > > that, I'm perfectly fine with maintainer sending pull request directly
> > > > to Linus (provided that I hadn't spotted something obviously wrong
> > > > in the series, of course, but that's not "I want it to go through
> > > > vfs.git" - that's "I don't want it in mainline until such and such
> > > > bug is resolved").
> > >
> > > let me take this opportunity to ask about another filesystem.
> > >
> > > Would you advise to send pull req for the fs/ntfs3 directly to Linus?
> > >
> > > That is a pending filesystem that happens to be highly expected by many
> > > Linux focused communities.
> > >
> > >
> > > Paragon Software GmbH proved it's commitment by sending as many as 26
> > > versions on it's patchset. The last set was send early April:
> > >
> > > [PATCH v26 00/10] NTFS read-write driver GPL implementation by Paragon Software
> > > https://marc.info/?l=linux-fsdevel&m=161738417018673&q=mbox
> > > https://patchwork.kernel.org/project/linux-fsdevel/list/?series=460291
> > >
> > >
> > > I'd say there weren't any serious issues raised since then.
> > >
> > > One Tested-by, one maintenance question, one remainder, one clang-12
> > > issue [0] [1].
> > >
> > > It seems this filesystem only needs:
> > > 1. [Requirement] Adjusting to the meanwhile changed iov API [2]
> > > 2. [Clean up] Using fs/iomap/ helpers [3]
> >
> > Why haven't those things been done and the patches resubmitted for
> > review? Nothing we can do from our side when the developers don't want
> > to submit a new series, right?
>
> The real issue (broken compilation) has been pointed out 2 days ago and
> is a result of a more recent commit. For months filesystem could be
> pushed but it wasn't for unknown reason.
>
> As for fs/iomap/ helpers it's unclear to me if that is really required
> or could be worked on later as a clean up. Darrick joked his opinion on
> using those helper is biased.

Porting to fs/iomap can be done after merge, so long as the ntfs3
driver doesn't depend on crazy reworking of buffer heads or whatever.
AFAICT it didn't, so ... yes, my earlier statements still apply: "later
as a clean up".

That said, I /really would/ like answers to the questions I posted here
about how well their fs driver fares while running fstests, since that's
probably the only way for community developers to ensure they don't
accidentally bitrot the driver into disk corruption land.

--D

[1] https://lore.kernel.org/linux-fsdevel/[email protected]/

> In short I'd say: missing feedback.

2021-07-14 16:19:24

by Rafał Miłecki

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

On 14.07.2021 18:05, Matthew Wilcox wrote:
> On Wed, Jul 14, 2021 at 05:59:19PM +0200, Rafał Miłecki wrote:
>> In short I'd say: missing feedback.
>
> Uh, with all due respect: Fuck you.
>
> I've provided feedback, and Paragon have done a fantastic job of
> responding to it. Pretending that the filesystem has simply been
> ignored is hugely disrespectful of my time and those at Paragon.
>
> I'm supportive of ntfs3 being included, FWIW. It looks to be
> in much better shape than the existing fs/ntfs.

Thanks you for kind words before even trying to clarify the situation.

What I meant (but failed to write clearly) is missing feedback on *the
latest* patchset.

I highly appreciate everyone who took time and helped polishing that
filesystem to its latest form.

2021-07-14 16:23:16

by Christoph Hellwig

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

On Wed, Jul 14, 2021 at 09:13:52AM -0700, Darrick J. Wong wrote:
> Porting to fs/iomap can be done after merge, so long as the ntfs3
> driver doesn't depend on crazy reworking of buffer heads or whatever.
> AFAICT it didn't, so ... yes, my earlier statements still apply: "later
> as a clean up".

I on the other hand hate piling up mor of this legacy stuff, as it tends
to not be cleaned up by the submitted. Example: erofs still hasn't
switched to iomap despite broad claims, also we still have a huge
backlog in the switch to the new mount API.

2021-07-14 16:40:10

by Gao Xiang

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

Hi Christoph,

On Wed, Jul 14, 2021 at 05:18:07PM +0100, Christoph Hellwig wrote:
> On Wed, Jul 14, 2021 at 09:13:52AM -0700, Darrick J. Wong wrote:
> > Porting to fs/iomap can be done after merge, so long as the ntfs3
> > driver doesn't depend on crazy reworking of buffer heads or whatever.
> > AFAICT it didn't, so ... yes, my earlier statements still apply: "later
> > as a clean up".
>
> I on the other hand hate piling up mor of this legacy stuff, as it tends
> to not be cleaned up by the submitted. Example: erofs still hasn't
> switched to iomap despite broad claims, also we still have a huge

Just some word of this, I've been always actively developing and
converting legacy stuffs to new APIs these years, such as new mount
APIs, xarray, which can be seen by changelog compared with other
filesystems. The iomap buffered I/O stuff is mainly because it
doesn't support tailing-packing inline, although which has been
requested for people who cares more about storage itself, like:
https://lore.kernel.org/lkml/[email protected]/
And I can also show the benefits by using tailing-packing inline
by taking Linux source code tree (many random tail blocks) as an
example...

I'm now working on this tailing-packing inline iomap support as
well. But Anyway, erofs didn't use buffer head in the beginning
since I can see some flew of buffer head approach itself, it just
works on raw bio and page cache interfaces for now.

Thanks,
Gao Xiang

> backlog in the switch to the new mount API.

2021-07-14 20:11:02

by Eric W. Beiderman

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

Christoph Hellwig <[email protected]> writes:

> also we still have a huge backlog in the switch to the new mount API.
^^^^^^^^^^^^^^
Speaking of code that ignored reviewer feedback.

Part of my feedback was that the new mount API has problems that make
it difficult to switch to.

Or is it your point that we let the new mount API be merged without a
conversion for all filesystems and a promise that the conversion would
get done after it was merged?

Eric

2021-07-15 21:53:24

by Neal Gompa

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

On Wed, Jul 15, 2021 at 12:18 PM "Rafał Miłecki" <[email protected]> wrote:
>
> What I meant (but failed to write clearly) is missing feedback on *the
> latest* patchset.
>
> I highly appreciate everyone who took time and helped polishing that
> filesystem to its latest form.

As the person who tested the latest ntfs3 patchset, and had tested
many of those iterations in the past, I would really like to see
this *finally* land in Linux 5.14.

However, I get the feeling it's not going to make it for 5.14 *or*
5.15, and it seems like Paragon became discouraged by the lack of
feedback on the latest revision.

I know that compared to all you awesome folks, I'm just a lowly
user, but it's been frustrating to see nothing happen for months
with something that has a seriously high impact for a lot of people.

It's a shame, because the ntfs3 driver is miles better than the
current ntfs one, and is a solid replacement for the unmaintained
ntfs-3g FUSE implementation.


--
真実はいつも一つ!/ Always, there's only one truth!

2021-07-15 22:18:14

by Darrick J. Wong

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

On Wed, Jul 14, 2021 at 05:18:07PM +0100, Christoph Hellwig wrote:
> On Wed, Jul 14, 2021 at 09:13:52AM -0700, Darrick J. Wong wrote:
> > Porting to fs/iomap can be done after merge, so long as the ntfs3
> > driver doesn't depend on crazy reworking of buffer heads or whatever.
> > AFAICT it didn't, so ... yes, my earlier statements still apply: "later
> > as a clean up".
>
> I on the other hand hate piling up mor of this legacy stuff, as it tends
> to not be cleaned up by the submitted. Example: erofs still hasn't
> switched to iomap despite broad claims,

<shrug> I was letting that one go while willy tries to land all the
folio surgery on the iomap code.

> also we still have a huge backlog in the switch to the new mount API.

That's true, though having /read/ the xfs conversion series, I'm not
surprised that most maintainers don't want to do the heavy lift
themselves.

--D

2021-07-16 11:51:26

by Leonidas P. Papadakos

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

On the subject of this merge, I have to stress that this ntfs driver (fs/ntfs3, which would probably replace fs/ntfs, right?) is an important feature, from a user perspective. It would mean having good support for a cross-platform filesystem suitable for hard drives. exFAT is welcome, but it's a simple filesystem for flash storage.

Relevant xkcd: https://xkcd.com/619/

I think Paragon has been very good about supporting this driver with 26 patchsets and in my mind it would be suitable for staging. I've seen the discussion slow down since May, and I've been excited to see this merged. This driver is already in a much better feature state than the old ntfs driver from 2001.

2021-07-16 18:09:43

by Linus Torvalds

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

On Fri, Jul 16, 2021 at 4:49 AM Leonidas P. Papadakos
<[email protected]> wrote:
>
> This driver is already in a much better feature state than the old ntfs driver from 2001.

If the new ntfs code has acks from people - and it sounds like it did
get them - and Paragon is expected to be the maintainer of it, then I
think Paragon should just make a git pull request for it.

That's assuming that it continues to be all in just fs/ntfs3/ (plus
fs/Kconfig, fs/Makefile and MAINTAINERS entries and whatever
documentation) and there are no other system-wide changes. Which I
don't think it had.

We simply don't have anybody to funnel new filesystems - the fsdevel
mailing list is good for comments and get feedback, but at some point
somebody just needs to actually submit it, and that's not what fsdevel
ends up doing.

The argument that "it's already in a much better state than the old
ntfs driver" may not be a very strong technical argument (not because
of any Paragon problems - just because the old ntfs driver is not
great), but it _is_ a fairly strong argument for merging the new one
from Paragon.

And I don't think there has been any huge _complaints_ about the code,
and I don't think there's been any sign that being outside the kernel
helps.

Linus

2021-07-17 16:49:49

by Pali Rohár

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

On Friday 16 July 2021 14:46:35 Leonidas P. Papadakos wrote:
> It would mean having good support for a cross-platform filesystem suitable for hard drives. exFAT is welcome, but it's a simple filesystem for flash storage.

FYI: There is also another cross-platform filesystem (Linux kernel,
Windows NT kernel, Mac OS X kernel) suitable for hard disks too with
POSIX permissions about which people do not know too much. It is UDF.