From: Ian Kent <raven@themaw.net>
To: Christian Brauner <brauner@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Bill O'Donnell <bodonnel@redhat.com>
Subject: Re: [GIT PULL for v6.7] autofs updates
Date: Tue, 31 Oct 2023 10:04:48 +0800 [thread overview]
Message-ID: <fa1e43f4-c703-762e-1b65-bd2c30e0cd3e@themaw.net> (raw)
In-Reply-To: <20231030-imponieren-tierzucht-1d1ef70bce3f@brauner>
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
next prev parent reply other threads:[~2023-10-31 2:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 14:33 [GIT PULL for v6.7] autofs updates Christian Brauner
2023-10-29 7:54 ` Ian Kent
2023-10-30 10:24 ` Christian Brauner
2023-10-31 2:04 ` Ian Kent [this message]
2023-10-30 14:28 ` Bill O'Donnell
2023-10-31 2:12 ` Ian Kent
2023-11-06 6:22 ` Ian Kent
2023-11-06 14:40 ` David Howells
2023-11-06 14:50 ` Christian Brauner
2023-10-30 20:05 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa1e43f4-c703-762e-1b65-bd2c30e0cd3e@themaw.net \
--to=raven@themaw.net \
--cc=bodonnel@redhat.com \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.