Re: [GIT PULL for v6.7] autofs updates

Re: [GIT PULL for v6.7] autofs updates

[Ian Kent]

On 27/10/23 22:33, Christian Brauner wrote:
> Hey Linus,
>
> /* Summary */
> This ports autofs to the new mount api. The patchset has existed for
> quite a while but never made it upstream. Ian picked it back up.
>
> This also fixes a bug where fs_param_is_fd() was passed a garbage
> param->dirfd but it expected it to be set to the fd that was used to set
> param->file otherwise result->uint_32 contains nonsense. So make sure
> it's set.
>
> One less filesystem using the old mount api. We're getting there, albeit
> rather slow. The last remaining major filesystem that hasn't converted
> is btrfs. Patches exist - I even wrote them - but so far they haven't
> made it upstream.

Yes, looks like about 39 still to be converted.


Just for information, excluding btrfs, what would you like to see as the

priority for conversion (in case me or any of my colleagues get a chance

to spend a bit more time on it)?


Ian

Re: [GIT PULL for v6.7] autofs updates

[Christian Brauner]

On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote:
> On 27/10/23 22:33, Christian Brauner wrote:
> > Hey Linus,
> > 
> > /* Summary */
> > This ports autofs to the new mount api. The patchset has existed for
> > quite a while but never made it upstream. Ian picked it back up.
> > 
> > This also fixes a bug where fs_param_is_fd() was passed a garbage
> > param->dirfd but it expected it to be set to the fd that was used to set
> > param->file otherwise result->uint_32 contains nonsense. So make sure
> > it's set.
> > 
> > One less filesystem using the old mount api. We're getting there, albeit
> > rather slow. The last remaining major filesystem that hasn't converted
> > is btrfs. Patches exist - I even wrote them - but so far they haven't
> > made it upstream.
> 
> Yes, looks like about 39 still to be converted.
> 
> 
> Just for information, excluding btrfs, what would you like to see as the
> 
> priority for conversion (in case me or any of my colleagues get a chance
> 
> to spend a bit more time on it)?

I think one way to prioritize them is by how likely they are to have
(more than a couple) active users.

So recently I've done overlayfs because aside from btrfs that was
probably one of the really actively used filesystems that hadn't yet
been converted. And that did surface some regression

So 9p, fat, devpts, f2fs, zonefs, ext2 are pretty obvious targets.
Judging from experience, the more mount options a filesystem has the
bigger the conversion patch will usually be.

Another way is by function. For example, we expose mount_bdev() which is
basically the legacy version of get_tree_bdev(). And they sort of are
almost copies of each other. So converting all callers to the new mount
api means we can get rid of mount_bdev(). But that's like 25 of the
remaining 39.

But in the end any filesystem that is converted is great.

Re: [GIT PULL for v6.7] autofs updates

[Bill O'Donnell]

On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote:
> On 27/10/23 22:33, Christian Brauner wrote:
> > Hey Linus,
> > 
> > /* Summary */
> > This ports autofs to the new mount api. The patchset has existed for
> > quite a while but never made it upstream. Ian picked it back up.
> > 
> > This also fixes a bug where fs_param_is_fd() was passed a garbage
> > param->dirfd but it expected it to be set to the fd that was used to set
> > param->file otherwise result->uint_32 contains nonsense. So make sure
> > it's set.
> > 
> > One less filesystem using the old mount api. We're getting there, albeit
> > rather slow. The last remaining major filesystem that hasn't converted
> > is btrfs. Patches exist - I even wrote them - but so far they haven't
> > made it upstream.
> 
> Yes, looks like about 39 still to be converted.
> 
> 
> Just for information, excluding btrfs, what would you like to see as the
> 
> priority for conversion (in case me or any of my colleagues get a chance
> 
> to spend a bit more time on it)?

I'm just starting to have a look at zonefs as a candidate.
-Bill

Re: [GIT PULL for v6.7] autofs updates

[pr-tracker-bot]

The pull request you sent on Fri, 27 Oct 2023 16:33:41 +0200:

> git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.7.autofs

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0d63d8b2294b228147bf58def506dde35e57daef

Thank you!

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

Re: [GIT PULL for v6.7] autofs updates

[Ian Kent]

On 30/10/23 18:24, Christian Brauner wrote:
> On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote:
>> On 27/10/23 22:33, Christian Brauner wrote:
>>> Hey Linus,
>>>
>>> /* Summary */
>>> This ports autofs to the new mount api. The patchset has existed for
>>> quite a while but never made it upstream. Ian picked it back up.
>>>
>>> This also fixes a bug where fs_param_is_fd() was passed a garbage
>>> param->dirfd but it expected it to be set to the fd that was used to set
>>> param->file otherwise result->uint_32 contains nonsense. So make sure
>>> it's set.
>>>
>>> One less filesystem using the old mount api. We're getting there, albeit
>>> rather slow. The last remaining major filesystem that hasn't converted
>>> is btrfs. Patches exist - I even wrote them - but so far they haven't
>>> made it upstream.
>> Yes, looks like about 39 still to be converted.
>>
>>
>> Just for information, excluding btrfs, what would you like to see as the
>>
>> priority for conversion (in case me or any of my colleagues get a chance
>>
>> to spend a bit more time on it)?
> I think one way to prioritize them is by how likely they are to have
> (more than a couple) active users.
>
> So recently I've done overlayfs because aside from btrfs that was
> probably one of the really actively used filesystems that hadn't yet
> been converted. And that did surface some regression
>
> So 9p, fat, devpts, f2fs, zonefs, ext2 are pretty obvious targets.
> Judging from experience, the more mount options a filesystem has the
> bigger the conversion patch will usually be.
>
> Another way is by function. For example, we expose mount_bdev() which is
> basically the legacy version of get_tree_bdev(). And they sort of are
> almost copies of each other. So converting all callers to the new mount
> api means we can get rid of mount_bdev(). But that's like 25 of the
> remaining 39.
>
> But in the end any filesystem that is converted is great.

Thanks Christian, I know Bill was considering spending a bit of time on

this and I may have some cycles myself in the not too distant future. But

things change all too quickly so we'll need to see how it goes, ;)


Ian


I'll

Re: [GIT PULL for v6.7] autofs updates

[Ian Kent]

On 30/10/23 22:28, Bill O'Donnell wrote:
> On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote:
>> On 27/10/23 22:33, Christian Brauner wrote:
>>> Hey Linus,
>>>
>>> /* Summary */
>>> This ports autofs to the new mount api. The patchset has existed for
>>> quite a while but never made it upstream. Ian picked it back up.
>>>
>>> This also fixes a bug where fs_param_is_fd() was passed a garbage
>>> param->dirfd but it expected it to be set to the fd that was used to set
>>> param->file otherwise result->uint_32 contains nonsense. So make sure
>>> it's set.
>>>
>>> One less filesystem using the old mount api. We're getting there, albeit
>>> rather slow. The last remaining major filesystem that hasn't converted
>>> is btrfs. Patches exist - I even wrote them - but so far they haven't
>>> made it upstream.
>> Yes, looks like about 39 still to be converted.
>>
>>
>> Just for information, excluding btrfs, what would you like to see as the
>>
>> priority for conversion (in case me or any of my colleagues get a chance
>>
>> to spend a bit more time on it)?
> I'm just starting to have a look at zonefs as a candidate.
> -Bill
>
And devpts looks fairly straight forward and is used a lot ... I'll see if

I can get time to get that one done, ;)


Ian

Re: [GIT PULL for v6.7] autofs updates

[Ian Kent]

On 31/10/23 10:12, Ian Kent wrote:
> On 30/10/23 22:28, Bill O'Donnell wrote:
>> On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote:
>>> On 27/10/23 22:33, Christian Brauner wrote:
>>>> Hey Linus,
>>>>
>>>> /* Summary */
>>>> This ports autofs to the new mount api. The patchset has existed for
>>>> quite a while but never made it upstream. Ian picked it back up.
>>>>
>>>> This also fixes a bug where fs_param_is_fd() was passed a garbage
>>>> param->dirfd but it expected it to be set to the fd that was used 
>>>> to set
>>>> param->file otherwise result->uint_32 contains nonsense. So make sure
>>>> it's set.
>>>>
>>>> One less filesystem using the old mount api. We're getting there, 
>>>> albeit
>>>> rather slow. The last remaining major filesystem that hasn't converted
>>>> is btrfs. Patches exist - I even wrote them - but so far they haven't
>>>> made it upstream.
>>> Yes, looks like about 39 still to be converted.
>>>
>>>
>>> Just for information, excluding btrfs, what would you like to see as 
>>> the
>>>
>>> priority for conversion (in case me or any of my colleagues get a 
>>> chance
>>>
>>> to spend a bit more time on it)?
>> I'm just starting to have a look at zonefs as a candidate.
>> -Bill
>>
> And devpts looks fairly straight forward and is used a lot ... I'll 
> see if
Christian, David's original conversion patch for devpts looks like it's

still relevant, it also looks fairly small to the point that I'm wondering

if it's worth breaking it down into smaller patches.


Would you be ok with me just doing a straight patch apply, detailed review

and some testing before posting it?


David, are you ok with me resurrecting your conversion patch and posting it

on your behalf?


Ian

Re: [GIT PULL for v6.7] autofs updates

[David Howells]

Ian Kent <raven@themaw.net> wrote:

> David, are you ok with me resurrecting your conversion patch and posting it
> on your behalf?

Yes, that's fine.

David

Re: [GIT PULL for v6.7] autofs updates

[Christian Brauner]

> Christian, David's original conversion patch for devpts looks like it's
> 
> still relevant, it also looks fairly small to the point that I'm wondering
> 
> if it's worth breaking it down into smaller patches.

I vaguely remember that patch and no, for simple fses like devpts
breaking this into smaller chunks is probably not worth it.

These conversions patches often aren't easy to split nicely anyway.

> Would you be ok with me just doing a straight patch apply, detailed review
> 
> and some testing before posting it?

Sure.